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: Thu, 3 Aug 2006 17:08:07 +0200 (CEST)
Hi Rocco and Thomas,
On Thursday, August 3, 2006 at 12:35:02 +0200, Rocco Rutte wrote:
> The problem is that mailbox expansion is applied to folder-hooks. I'd
> call this a feature
Good catch! The ^ current folder expands to nothing at startup
muttrc parsing time. The same regexp entered interactively
":folder-hook ^ABC$ yaddahyaddah" while in nomatchABC folder expands to
"nomatchABCABC$". And this explains why this fleature exists only since
1.5.10, when current folder patch was commited.
> case-sensivity doesn't matter
Right. I was confused about forced caseful matching even when the
regexp is only lowcase. "^abc$" didn't wrongly match "nomatchABC", but
not because of the not eaten anchor.
> Basically we need a way to distinct between regex and "folder" special
> characters.
<brainstorming> Is there really a problem outside of "^"? Other
shortcuts are "! > < - !! ~ = + @". All of them expand only when in
first position. But even if backslashed. "~ = +" are directories, that
may have to be followed by more characters. Others are directly a
folder's name. What about expanding those last only when they are alone
in string? Like expand "^" to "/tmp/nomatchABC", but keep "^a" as
regexp?
Otherwise: Why are they expanded if backslashed? They don't need to
(outside of ! because of ! negation)? "^a" could be expanded to
"/tmp/nomatchABCa", but "\^a" to "^a" regexp. Hum... One backslash is
stripped too early, right?
They are not expanded if double\\ed. One backslash reaches the
regexp engine. This doesn't hurt normal chars, but of course hurts "^".
Grrr...
BTW today "^^a" expands to "^a". But it's a false friend: That
"works" only at startup; At runtime it expands to "/tmp/nomatchABC^a"
Why is "^" expanded at all in folder-hook patterns? It doesn't seem
to make much sense (because of empty expansion at startup). Hum... It
makes sense elsewhere, and crafting a special case for FHs would be
unclean, right? </brainstorming>
On Thursday, August 3, 2006 at 13:05:01 +0200, Thomas Roessler wrote:
> Would we lose much by having hooks *either* do regular expression
> matching *or* mailbox shortcuts?
We would lose "=IN.mutt-(users|dev)$", yes.
Bye! Alain.
--
Mutt muttrc tip for mailing lists: set followup_to=yes and declare the list as
- subscribe ^list@ddress$ if you are subscribed and don't want courtesy copy.
- lists ^list@ddress$ if you are not subscribed or want a courtesy copy.