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