On 2008-11-11, Kyle Wheeler <[EMAIL PROTECTED]> 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
