From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: dr.johannes.bruegmann@gmail.com (Dr. Johannes =?utf-8?Q?Br=C3=BCgman?= =?utf-8?Q?n?=) Newsgroups: gmane.emacs.bugs Subject: Re: bug#32609: 26.1; mail-strip-quoted-names:205 Date: Sun, 02 Sep 2018 14:56:35 +0200 Organization: A noiseless patient Spider Message-ID: <86sh2s6osc.fsf@gmail.com> References: <86y3ckkjgx.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1535902257 1671 195.159.176.226 (2 Sep 2018 15:30:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Sep 2018 15:30:57 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (windows-nt) To: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 02 17:30:52 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fwUKy-0000HG-PE for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Sep 2018 17:30:52 +0200 Original-Received: from localhost ([::1]:41393 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fwUN4-0007NV-KT for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Sep 2018 11:33:02 -0400 X-Received: by 2002:adf:8231:: with SMTP id 46-v6mr1973993wrb.12.1535892997232; Sun, 02 Sep 2018 05:56:37 -0700 (PDT) Original-Path: usenet.stanford.edu!q200-v6no6748099wmd.0!news-out.google.com!a22-v6ni24096wmg.0!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder2.ecngs.de!78.46.240.70.MISMATCH!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.bug Original-Lines: 54 Original-Injection-Info: reader02.eternal-september.org; posting-host="d71a3f45ff9a47928971236bf00d19aa"; logging-data="18948"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+npGxkreAFSjfTJ1HHb2l6" Cancel-Lock: sha1:jcCp6TXS9yI5Liyq8UOixw/c+8Y= sha1:WnESQECmT8R8hnSfYW02lcGfEm0= Original-Xref: usenet.stanford.edu gnu.emacs.bug:168118 X-Mailman-Approved-At: Sun, 02 Sep 2018 11:32:57 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:149966 Archived-At: Noam Postavsky writes: > tags 32609 + moreinfo > quit > > Johannes Bruegmann 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.