Re: Replying to a specific message
On Wed, Aug 27, 2008 at 12:54 AM, Kyle Wheeler <kyle-mutt@xxxxxxxxxxxxxx> wrote:
> On Tuesday, August 26 at 11:46 PM, quoth Shreevatsa R:
>>> Skip the escaping, and just use quotes:
>>>
>>> mutt -e "push '<limit>~i "$MID"<Enter><group-reply>'" $@
>>>
>>> AFAIK quote characters aren't allowed in Message-IDs.
>>
>> That's probably true, but quotes don't work. Start mutt and do
>> <limit>~i "<a$b@c>" and it *won't* match Message-ID: <a$b@c>". Neither
>> will ~i '<a$b@c>' nor ~i "<a\$b@c>"; the only things that work are ~i
>> '<a\$b@c>' or ~i <a\\$b@c> or ~i "<a\\$b@c>" (but not ~i '<a\\$b@c>').
>> I would consider this behaviour a bug in mutt, probably some would
>> not, so I didn't mention it the last time. Is there a reason things
>> are this way? (A design reason, not "that's how it happens to be
>> implemented".)
>
> Well, part of the problem is your shell, which eats some of the quotes
> (and can potentially eat the $) before mutt ever sees them.
Yes, this is the easiest part of the puzzle, and also easiest to fix :)
[Given that the shell is familiar, can provide arbitrary feedback, etc.]
This is also why I phrased everything in my previous email as "from
within mutt"; to avoid shell complications and focus on the mutt ones.
> The other thing to keep in mind is that the ~i simple pattern takes a
> regular expression as an argument, rather than a simple string.
Yes, but it *could* have been made to understand text within " " (or
within ' ', or anything, really) as a string that must be interpreted
literally.
> Anyway, there's an additional problem,
> which is that there's an extra set of de-quoting (and de-escaping)
> that goes on, which is in interpreting the argument to ~i. The reason
Yes, this is the other problem.
> for this is to distinguish between a compound match that matches
> message ID and potentially something else (e.g. ~i foo ~s subj) and a
> long and strange matching string (e.g. ~i "foo ~s subj" or even ~i
> foo\ ~s\ subj).
I don't buy this. Mutt could easily have a system to distinguish
between such cases (see below), it just happens not to.
> Mutt sees:
> push "<limit>~i <a\\$b><enter>"
> Mutt's pattern parser sees:
> ~i <a\$b>
> Mutt's regex engine sees:
> <a$b> (remember: $ != [$])
The latter step is poor design. There is no reason that mutt cannot be
made to remember its strings; it is parsing too often.
Mutt should handle its strings itself without making the user have to
spend the effort.
> Does that make sense?
Everything "makes sense" in that it is understandable what is
happening. (And thank you for explaining, I understand it better now
than I thought I did before.)
It is not sufficient justification for being that way, however. Why
can't the regex engine see the same strings that the pattern parser
sees? Why is mutt parsing so often?
The only "parsing" that the pattern parser needs to do is break up the
user-input string into "logical parts" of the form (~i EXPR), (~s
EXPR), etc., and then each corresponding part can do its job with the
actual string that was input. (The parser might also have to do some
logical AND/OR/NOT operations, but that's later.) It has no reason to
poke at the actual EXPR strings and mess with them. The parser already
has a () logical grouping operator; I maintain that this is all it
needs. By simply refusing to interpret
~i foo\ and\ bar
as one argument to ~i and instead requiring either ~i "foo and bar" or
~i (foo and bar), it can completely do away with the extra dequoting
step and pass to the regex engine the same strings it gets, intact. It
spends an extra step parsing the string and dequoting all characters,
when all it needs to do is something much simpler.
Anyway, nevermind this rant; back to the original question: Given that
mutt has no syntax for specifying that a string must be interpreted
literally (an annoying omission), "escaping" is necessary. Simply
replacing each $ with \\$ (or with [$]) works for everything I have
encountered, so the question is entirely hypothetical: what more might
I have to worry about, and has anyone thought about the problem of
escaping a string for mutt and solved it? There is no consistency to
speak of among regular expression implementations; each has its own
quirks; and simply using another language's "escape" function might
not work with mutt.
-S