Re: mutt/2402: damaged regexps in folder-hooks
The following reply was made to PR mutt/2402; it has been noted by GNATS.
From: Alain Bench <veronatif@xxxxxxx>
To: bug-any@xxxxxxxxxxxxx
Cc:
Subject: Re: mutt/2402: damaged regexps in folder-hooks
Date: Fri, 4 Aug 2006 07:37:24 +0200 (CEST)
On Thursday, August 3, 2006 at 17:45:03 +0200, Rocco Rutte wrote:
>> Grrr...
> So you tried it, too? :)
At last! Found *the* working syntax. Tadaa!
| folder-hook (^ABC$) yaddahyaddah
This expands to self:
| Status of commands:
|
| folder-hook
| (^ABC$)
| yaddahyaddah
...and regexec seems to like it. No problem for negation:
| folder-hook !(^ABC$) yaddahyaddah
...expands to:
| folder-hook
| !( (^ABC$) )
| yaddahyaddah
...and works as expected. So it's maybe just a matter of documenting
it. Something like: "To prevent the expansion of mailbox shortcut
characters that you would want to use as special characters in the
regexp, enclose the whole regexp in parenthesis. Example: If you want to
match ^regexp$ exactly, without the default automagic expansion of "^"
shortcut to the full name of the current folder, then use (^regexp$) as
pattern. This is needed only for folder-hook patterns, the only ones to
first endure folder expansion, and then pursue a regexp career."
On Thursday, August 3, 2006 at 18:55:02 +0200, Brendan Cully wrote:
> On Thursday, 03 August 2006 at 17:45, Rocco Rutte wrote:
>> rename '^' to something else
> the only sensible thing to do. Let's use '.' instead :)
And a nice enhancement would be to defer its expansion, so default
folder-hooks can continue to work... ;-)
> I don't think '^' has been in use long enough to warrant
> backward-compatibility hacks.
Before its inclusion in Mutt, the "^" shortcut had a long career as
a feature patch, and was used by many people since years. Even included
in Debian packages.
On Thursday, August 3, 2006 at 17:59:14 +0200, Rado Smiljanic wrote:
>> * Alain Bench [06-08-03 17:15:01 +0200] wrote:
>>> shortcuts are "! > < - !! ~ = + @". All of them expand only when in
>>> first position.
> If you want to match absolute path names to be sure it doesn't match a
> subdir, then ^! or ^< for example wouldn't work.
Right: Strict regexp around a shortcut is not possible. And I can't
resist to think it's unfortunate. Hum... <BS> This could be done
automatically at expansion. When expanding shortcuts for wanabee
regexps, we could regexpify path names ^dir\.ext or ^file\.ext$ </BS>
Probable overkill. BS means here no br*inst*rming, but bullshit. ;-)
Bye! Alain.
--
$ ln -s imap://veronatif@xxxxxxxxxxxx/INBOX/ remote-inbox
create symbolic link remote-inbox to imap://veronatif@xxxxxxxxxxxx/INBOX/
$ mutt-cvs -f remote-inbox
remote-inbox: No such file or directory (errno = 2)