Re: bug#32609: 26.1; mail-strip-quoted-names:205

[dr.johannes.bruegmann@gmail.com (Dr. Johannes Brügmann)]

Noam Postavsky <npostavs@gmail.com> writes:

> tags 32609 + moreinfo
> quit
>
> Johannes Bruegmann <johannes.bruegmann@web.de> writes:
>
>> I   tried  to   reply  to   an  email   by  pressing   r,  R,   and  M-x
>> gnus-article-reply-with-original.   None  of  them  worked.   Minibuffer
>> displayed  "Mark  Set" but  nothing  happened.  I enabled  Debugging  on
>> C-g. The *Backtrace*-buffer showed
>>      string-match("\\`[ \t\n]*" "")
>>      mail-strip-quoted-names("")
>>      mail-dont-reply-to("foo@bar.com")
>
> If I evaluate (mail-dont-reply-to "foo@bar.com") it doesn't hang.  I
> guess "foo@bar.com" is a placeholder, but you've dropped the relevant
> special characters that cause the problem.  Can you give a value that
> reproduces the hang?  E.g., just change all letters in the real email to
> x, but leave other characters untouched.

The  mail address  i  wanted  to reply  to  didn't  contain any  special
characters.  Neither did  the call  to mail-dont-reply-to.  I understand
that special characters could cause such a behaviour.

As part of following your question, I've put the original file back into
its place, and  then i recompiled using  byte-compile-file and restarted
emacs.   Now the  symtom is  no  longer reproducible.  Neither with  the
originating email, nor with any others that i tested.

>> To me it  looked like that the signature for  string-match and match-end
>> changed   (or   have   been   overloaded?).  Anyway,   when   i   change
>
> Not sure what you mean about signature change.

I  didn't   look  very   carefully  at   the  function   description  of
string-match.   I was  wondering why  someone would  not use  the return
value  of string-match.  Now  i understand  that  string-match holds  an
internal state and match-end can be used to get beyond the first match.

>> mail-utils.el:205 into
>>      ;; strip surrounding whitespace
>>      (setq address (substring address
>>                               (string-match "\\`[ \t\n]*" address)
>>                               (string-match "[ \t\n]*\\'" address
>>                               (match-end 0))))
>>
>> things work for me.
>
> I don't  think this change is  correct, it doesn't remove  the leading
> whitespace like before.

You are  right here.  But still i  didn't dream the  symptom :)  nor the
backtrace.