<<< Date Index >>>     <<< Thread Index >>>

Re: regression between revisions 5546 and 5554



* Thu Nov 20 2008 Fabian Groffen <grobian@xxxxxxxxxx>
> On 20-11-2008 16:24:04 +0900, TAKAHASHI Tamotsu wrote:
> > * Wed Nov 19 2008 Fabian Groffen <grobian@xxxxxxxxxx>
> > > On 18-11-2008 12:39:31 +0100, Jukka Salmi wrote:
> > > > > Hmm, is anybody else seing this as well?
> > > 
> > > I a similar problem on Cyrus.  I can't access mailboxes that are above
> > > my ../INBOX folder, e.g. the ../shared.XXX folder.  Mutt claims the
> > > mailbox does not exist, whereas plain 1.5.18 can find the folder fine.
> > > The browser can see the folder though.
> > 
> > How do you reproduce it from "mutt -nF /dev/null" ?
> > I set up Cyrus IMAPD 2.3.13 with unixhierachysep=1, and I can
> > do "mutt -nF /dev/null -f imap://localhost/INBOX.second.third"
> > with my patch.
> 
> I can't tell you at the moment what you want to know here, but that the
> problem only happens for imap://host/shared.folder, where the folder
> name is really called "shared.folder".  It isn't a folder subdir of
> shared.  I guess the culprit lies in here.

Ah, I see! Thanks for explaining precisely enough.
Well, then I don't know whether it is bug or not.
The manual says:

# Name: imap_delim_chars
# Type: string
# Default: "/."
#
#
# This contains the list of characters which you would like to treat
# as folder separators for displaying IMAP paths.
                           ^^^^^^^^^^

I'm not sure the word "displaying" explicitly limits the
effect of the variable, or not.

But IMHO the new behavior (i.e. to translate anything in
$imap_delim_chars to the server's delim char or to the first
char of $imap_delim_chars) is more natural than the old one.
So I think you should use "/" as *the* solution, not a work-
around. But I don't know what brendan will say.

If we have to allow "." regardless $imap_delim_chars, many
imap_fix_path()s will be deleted or changed, and much
inconvenience will be introduced, I guess.

-- 
tamo