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.