Re: mutt/2402: damaged regexps in folder-hooks
The following reply was made to PR mutt/2402; it has been noted by GNATS.
From: Rocco Rutte <pdmef@xxxxxxx>
To: bug-any@xxxxxxxxxxxxx
Cc:
Subject: Re: mutt/2402: damaged regexps in folder-hooks
Date: Thu, 3 Aug 2006 15:36:03 +0000
Hi,
* Alain Bench [06-08-03 17:15:01 +0200] wrote:
> <brainstorming> Is there really a problem outside of "^"? Other
> shortcuts are "! > < - !! ~ = + @". All of them expand only when in
> first position.
Right.
> 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?
Yepp: already when reading/tokenizing the line.
> They are not expanded if double\\ed. One backslash reaches the
> regexp engine. This doesn't hurt normal chars, but of course hurts "^".
> Grrr...
So you tried it, too? :)
Another idea: we simply rename '^' to something else and announce that
with big fat warnings. We can continue to support '^' except for when
_mutt_expand_path() get's a regexp. That would add an extra 'case' label
as well as a check for the rx parameter.
Almost no setup would break (that isn't broken already) and almost
nobody would have to migrate to a new syntax.
Before we do something like this, we still would have to make sure to
locate all places where a regex-enabled path is expanded.
Oh, hook.c is (at it seems) the only where a regex-enabled folder is
used, so I'd give this idea a "go"... :)
More opinions?
bye, Rocco
--
:wq!