Re: reply_regex bug on Linux?
On 2008-11-11, Kyle Wheeler <kyle-mutt-dev@xxxxxxxxxxxxxx> wrote:
> On Tuesday, November 11 at 12:18 AM, quoth Gary Johnson:
>> Is this a known problem or should I investigate further?
>
> Are you using mutt's internal regex engine? Try recompiling mutt with the
> --with-regex option and see if that doesn't fix it. If it does, then the
> problem is just that your Linux box has a broken regex library.
Thanks for the suggestion. I tried that. It made no difference.
I continued with some of the experiments I reported earlier but I
was seeing inconsistent results--it seemed that I couldn't reliably
reset the default value of 'reply_regex' from mutt's command
line--so I tried a different approach.
As I reported in another thread, I built a new version of mutt from
the latest development sources in mercurial. I then started with
the default value of 'reply_regex' and gradually built toward the
one I usually use, testing the reply function at each stage. It
worked fine until I added a particular term to the 'reply_regex'
expression. That term contained some non-ASCII characters that have
appeared in place of "Re" in replies I've received from Outlook
users in Beijing. Apparently my Solaris mutt read those characters
just as literal characters in the expression while my Linux mutt
interprets them as something else--I don't know what. I also don't
know if the differing interpretation occurs in the regular
expression engine or when mutt parses the line.
The term I added, after "|aw", was
|\347\255.\345\244.
I originally used the literal characters rather than their octal
equivalents. It didn't seem to make any difference to the behavior
of 'reply_regex' and I thought the octal form would work better in
this e-mail.
For now, I'm going to remove that term from my 'reply_regex'. If I
receive any more messages from Beijing that don't thread properly,
I'll restore that term and try to find out then what mutt is doing
with it.
Regards,
Gary