send new reply from gnus hangs

send new reply from gnus hangs

[Andy Moreton]

Hi,

A recent change on the master branch (within the last week) prevents
gnus from sending replies to newsgroups - it gets stuck with
"sending..." in the message area.

I've looked at the recent commits that might affect gnus, but nothing
obvious jumps out. I'm not sure what the problem is or how to start
debugging it.

Does anyone have any ideas ?

    AndyM

Re: send new reply from gnus hangs

[Óscar Fuentes]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> A recent change on the master branch (within the last week) prevents
> gnus from sending replies to newsgroups - it gets stuck with
> "sending..." in the message area.
>
> I've looked at the recent commits that might affect gnus, but nothing
> obvious jumps out. I'm not sure what the problem is or how to start
> debugging it.
>
> Does anyone have any ideas ?

git bisect

Re: send new reply from gnus hangs

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Andy Moreton <andrewjmoreton@gmail.com> writes:
>
>> A recent change on the master branch (within the last week) prevents
>> gnus from sending replies to newsgroups - it gets stuck with
>> "sending..." in the message area.
>>
>> I've looked at the recent commits that might affect gnus, but nothing
>> obvious jumps out. I'm not sure what the problem is or how to start
>> debugging it.
>>
>> Does anyone have any ideas ?
>
> git bisect

f113512ffc works

Re: send new reply from gnus hangs

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>
>>> A recent change on the master branch (within the last week) prevents
>>> gnus from sending replies to newsgroups - it gets stuck with
>>> "sending..." in the message area.
>>>
>>> I've looked at the recent commits that might affect gnus, but nothing
>>> obvious jumps out. I'm not sure what the problem is or how to start
>>> debugging it.
>>>
>>> Does anyone have any ideas ?
>>
>> git bisect
>
> f113512ffc works

10582d05 works, but the step at 60286626 and f2a7acdd suffer from a
different problem:

Debugger entered--Lisp error: (void-function gnus-data-find-in)
  gnus-data-find-in(237368 ((237368 32 2 [237368 "Re: send new reply from gnus hangs" "Óscar Fuentes <ofv@wanadoo.es>" "Mon, 10 Jun 2019 00:47:56 +0200" "<87k1duml43.fsf@telefonica.net>" "<vz1d0jprt2e.fsf@gmail.com> <87r285nhxb.fsf@telefo..." 3937 20 "news.gmane.org gmane.emacs.devel:237368" nil] 0)))
  gnus-request-article-this-buffer(237368 "gmane.emacs.devel")
  gnus-article-prepare(237368 nil)
  gnus-summary-display-article(237368 nil)
  gnus-summary-select-article(nil nil pseudo)
  gnus-summary-scroll-up(1)
  funcall-interactively(gnus-summary-scroll-up 1)
  call-interactively(gnus-summary-scroll-up nil nil)
  command-execute(gnus-summary-scroll-up)


Probably the bisection is useless because this bug was fixed or
superseded by the bug that causes the hang.

Re: send new reply from gnus hangs

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>
>>> A recent change on the master branch (within the last week) prevents
>>> gnus from sending replies to newsgroups - it gets stuck with
>>> "sending..." in the message area.
>>>
>>> I've looked at the recent commits that might affect gnus, but nothing
>>> obvious jumps out. I'm not sure what the problem is or how to start
>>> debugging it.
>>>
>>> Does anyone have any ideas ?
>>
>> git bisect
>
> f113512ffc works

a0c7a640c2 works.

Re: send new reply from gnus hangs

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>>
>>>> A recent change on the master branch (within the last week) prevents
>>>> gnus from sending replies to newsgroups - it gets stuck with
>>>> "sending..." in the message area.
>>>>
>>>> I've looked at the recent commits that might affect gnus, but nothing
>>>> obvious jumps out. I'm not sure what the problem is or how to start
>>>> debugging it.
>>>>
>>>> Does anyone have any ideas ?
>>>
>>> git bisect
>>
>> f113512ffc works
>
> 10582d05 works, but the step at 60286626 and f2a7acdd suffer from a
> different problem:
>
> Debugger entered--Lisp error: (void-function gnus-data-find-in)
>   gnus-data-find-in(237368 ((237368 32 2 [237368 "Re: send new reply
> from gnus hangs" "Óscar Fuentes <ofv@wanadoo.es>" "Mon, 10 Jun 2019
> 00:47:56 +0200" "<87k1duml43.fsf@telefonica.net>"
> "<vz1d0jprt2e.fsf@gmail.com> <87r285nhxb.fsf@telefo..." 3937 20
> "news.gmane.org gmane.emacs.devel:237368" nil] 0)))
>   gnus-request-article-this-buffer(237368 "gmane.emacs.devel")
>   gnus-article-prepare(237368 nil)
>   gnus-summary-display-article(237368 nil)
>   gnus-summary-select-article(nil nil pseudo)
>   gnus-summary-scroll-up(1)
>   funcall-interactively(gnus-summary-scroll-up 1)
>   call-interactively(gnus-summary-scroll-up nil nil)
>   command-execute(gnus-summary-scroll-up)
>
>
> Probably the bisection is useless because this bug was fixed or
> superseded by the bug that causes the hang.

40bc7ddb75 works.

Re: send new reply from gnus hangs

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>>
>>>> A recent change on the master branch (within the last week) prevents
>>>> gnus from sending replies to newsgroups - it gets stuck with
>>>> "sending..." in the message area.
>>>>
>>>> I've looked at the recent commits that might affect gnus, but nothing
>>>> obvious jumps out. I'm not sure what the problem is or how to start
>>>> debugging it.
>>>>
>>>> Does anyone have any ideas ?
>>>
>>> git bisect
>>
>> f113512ffc works
>
> 10582d05 works, but the step at 60286626 and f2a7acdd suffer from a
> different problem:
>
> Debugger entered--Lisp error: (void-function gnus-data-find-in)
>   gnus-data-find-in(237368 ((237368 32 2 [237368 "Re: send new reply
> from gnus hangs" "Óscar Fuentes <ofv@wanadoo.es>" "Mon, 10 Jun 2019
> 00:47:56 +0200" "<87k1duml43.fsf@telefonica.net>"
> "<vz1d0jprt2e.fsf@gmail.com> <87r285nhxb.fsf@telefo..." 3937 20
> "news.gmane.org gmane.emacs.devel:237368" nil] 0)))
>   gnus-request-article-this-buffer(237368 "gmane.emacs.devel")
>   gnus-article-prepare(237368 nil)
>   gnus-summary-display-article(237368 nil)
>   gnus-summary-select-article(nil nil pseudo)
>   gnus-summary-scroll-up(1)
>   funcall-interactively(gnus-summary-scroll-up 1)
>   call-interactively(gnus-summary-scroll-up nil nil)
>   command-execute(gnus-summary-scroll-up)
>
>
> Probably the bisection is useless because this bug was fixed or
> superseded by the bug that causes the hang.

12f530a73 works.

Re: send new reply from gnus hangs

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>>
>>>> A recent change on the master branch (within the last week) prevents
>>>> gnus from sending replies to newsgroups - it gets stuck with
>>>> "sending..." in the message area.
>>>>
>>>> I've looked at the recent commits that might affect gnus, but nothing
>>>> obvious jumps out. I'm not sure what the problem is or how to start
>>>> debugging it.
>>>>
>>>> Does anyone have any ideas ?
>>>
>>> git bisect
>>
>> f113512ffc works
>
> 10582d05 works, but the step at 60286626 and f2a7acdd suffer from a
> different problem:
>
> Debugger entered--Lisp error: (void-function gnus-data-find-in)
>   gnus-data-find-in(237368 ((237368 32 2 [237368 "Re: send new reply
> from gnus hangs" "Óscar Fuentes <ofv@wanadoo.es>" "Mon, 10 Jun 2019
> 00:47:56 +0200" "<87k1duml43.fsf@telefonica.net>"
> "<vz1d0jprt2e.fsf@gmail.com> <87r285nhxb.fsf@telefo..." 3937 20
> "news.gmane.org gmane.emacs.devel:237368" nil] 0)))
>   gnus-request-article-this-buffer(237368 "gmane.emacs.devel")
>   gnus-article-prepare(237368 nil)
>   gnus-summary-display-article(237368 nil)
>   gnus-summary-select-article(nil nil pseudo)
>   gnus-summary-scroll-up(1)
>   funcall-interactively(gnus-summary-scroll-up 1)
>   call-interactively(gnus-summary-scroll-up nil nil)
>   command-execute(gnus-summary-scroll-up)
>
>
> Probably the bisection is useless because this bug was fixed or
> superseded by the bug that causes the hang.


b6c628a16b52 works.

Re: send new reply from gnus hangs

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>>
>>>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>>>
>>>>> A recent change on the master branch (within the last week) prevents
>>>>> gnus from sending replies to newsgroups - it gets stuck with
>>>>> "sending..." in the message area.
>>>>>
>>>>> I've looked at the recent commits that might affect gnus, but nothing
>>>>> obvious jumps out. I'm not sure what the problem is or how to start
>>>>> debugging it.
>>>>>
>>>>> Does anyone have any ideas ?
>>>>
>>>> git bisect
>>>
>>> f113512ffc works
>>
>> 10582d05 works, but the step at 60286626 and f2a7acdd suffer from a
>> different problem:
>>
>> Debugger entered--Lisp error: (void-function gnus-data-find-in)
>>   gnus-data-find-in(237368 ((237368 32 2 [237368 "Re: send new reply
>> from gnus hangs" "Óscar Fuentes <ofv@wanadoo.es>" "Mon, 10 Jun 2019
>> 00:47:56 +0200" "<87k1duml43.fsf@telefonica.net>"
>> "<vz1d0jprt2e.fsf@gmail.com> <87r285nhxb.fsf@telefo..." 3937 20
>> "news.gmane.org gmane.emacs.devel:237368" nil] 0)))
>>   gnus-request-article-this-buffer(237368 "gmane.emacs.devel")
>>   gnus-article-prepare(237368 nil)
>>   gnus-summary-display-article(237368 nil)
>>   gnus-summary-select-article(nil nil pseudo)
>>   gnus-summary-scroll-up(1)
>>   funcall-interactively(gnus-summary-scroll-up 1)
>>   call-interactively(gnus-summary-scroll-up nil nil)
>>   command-execute(gnus-summary-scroll-up)
>>
>>
>> Probably the bisection is useless because this bug was fixed or
>> superseded by the bug that causes the hang.
>
> 40bc7ddb75 works.

f2a7acdde7207f9 is the supposed bad commit, which makes no sense.

Once again, bisecting Emacs turns nothing of value. sigh.

Let's try "human-guided" bisecting.

Re: send new reply from gnus hangs

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>>
>>>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>>>
>>>>> A recent change on the master branch (within the last week) prevents
>>>>> gnus from sending replies to newsgroups - it gets stuck with
>>>>> "sending..." in the message area.
>>>>>
>>>>> I've looked at the recent commits that might affect gnus, but nothing
>>>>> obvious jumps out. I'm not sure what the problem is or how to start
>>>>> debugging it.
>>>>>
>>>>> Does anyone have any ideas ?
>>>>
>>>> git bisect
>>>
>>> f113512ffc works
>>
>> 10582d05 works, but the step at 60286626 and f2a7acdd suffer from a
>> different problem:
>>
>> Debugger entered--Lisp error: (void-function gnus-data-find-in)
>>   gnus-data-find-in(237368 ((237368 32 2 [237368 "Re: send new reply
>> from gnus hangs" "Óscar Fuentes <ofv@wanadoo.es>" "Mon, 10 Jun 2019
>> 00:47:56 +0200" "<87k1duml43.fsf@telefonica.net>"
>> "<vz1d0jprt2e.fsf@gmail.com> <87r285nhxb.fsf@telefo..." 3937 20
>> "news.gmane.org gmane.emacs.devel:237368" nil] 0)))
>>   gnus-request-article-this-buffer(237368 "gmane.emacs.devel")
>>   gnus-article-prepare(237368 nil)
>>   gnus-summary-display-article(237368 nil)
>>   gnus-summary-select-article(nil nil pseudo)
>>   gnus-summary-scroll-up(1)
>>   funcall-interactively(gnus-summary-scroll-up 1)
>>   call-interactively(gnus-summary-scroll-up nil nil)
>>   command-execute(gnus-summary-scroll-up)
>>
>>
>> Probably the bisection is useless because this bug was fixed or
>> superseded by the bug that causes the hang.
>
>
> b6c628a16b52 works.


323648bf3603c9ea works.

Re: send new reply from gnus hangs

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>>
>>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>>>
>>>>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>>>>
>>>>>> A recent change on the master branch (within the last week) prevents
>>>>>> gnus from sending replies to newsgroups - it gets stuck with
>>>>>> "sending..." in the message area.
>>>>>>
>>>>>> I've looked at the recent commits that might affect gnus, but nothing
>>>>>> obvious jumps out. I'm not sure what the problem is or how to start
>>>>>> debugging it.
>>>>>>
>>>>>> Does anyone have any ideas ?
>>>>>
>>>>> git bisect
>>>>
>>>> f113512ffc works
>>>
>>> 10582d05 works, but the step at 60286626 and f2a7acdd suffer from a
>>> different problem:
>>>
>>> Debugger entered--Lisp error: (void-function gnus-data-find-in)
>>>   gnus-data-find-in(237368 ((237368 32 2 [237368 "Re: send new reply
>>> from gnus hangs" "Óscar Fuentes <ofv@wanadoo.es>" "Mon, 10 Jun 2019
>>> 00:47:56 +0200" "<87k1duml43.fsf@telefonica.net>"
>>> "<vz1d0jprt2e.fsf@gmail.com> <87r285nhxb.fsf@telefo..." 3937 20
>>> "news.gmane.org gmane.emacs.devel:237368" nil] 0)))
>>>   gnus-request-article-this-buffer(237368 "gmane.emacs.devel")
>>>   gnus-article-prepare(237368 nil)
>>>   gnus-summary-display-article(237368 nil)
>>>   gnus-summary-select-article(nil nil pseudo)
>>>   gnus-summary-scroll-up(1)
>>>   funcall-interactively(gnus-summary-scroll-up 1)
>>>   call-interactively(gnus-summary-scroll-up nil nil)
>>>   command-execute(gnus-summary-scroll-up)
>>>
>>>
>>> Probably the bisection is useless because this bug was fixed or
>>> superseded by the bug that causes the hang.
>>
>> 40bc7ddb75 works.
>
> f2a7acdde7207f9 is the supposed bad commit, which makes no sense.
>
> Once again, bisecting Emacs turns nothing of value. sigh.
>
> Let's try "human-guided" bisecting.

dd7bc5de3f59 works.

Re: send new reply from gnus hangs

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>>
>>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>>>
>>>>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>>>>
>>>>>> A recent change on the master branch (within the last week) prevents
>>>>>> gnus from sending replies to newsgroups - it gets stuck with
>>>>>> "sending..." in the message area.
>>>>>>
>>>>>> I've looked at the recent commits that might affect gnus, but nothing
>>>>>> obvious jumps out. I'm not sure what the problem is or how to start
>>>>>> debugging it.
>>>>>>
>>>>>> Does anyone have any ideas ?
>>>>>
>>>>> git bisect
>>>>
>>>> f113512ffc works
>>>
>>> 10582d05 works, but the step at 60286626 and f2a7acdd suffer from a
>>> different problem:
>>>
>>> Debugger entered--Lisp error: (void-function gnus-data-find-in)
>>>   gnus-data-find-in(237368 ((237368 32 2 [237368 "Re: send new reply
>>> from gnus hangs" "Óscar Fuentes <ofv@wanadoo.es>" "Mon, 10 Jun 2019
>>> 00:47:56 +0200" "<87k1duml43.fsf@telefonica.net>"
>>> "<vz1d0jprt2e.fsf@gmail.com> <87r285nhxb.fsf@telefo..." 3937 20
>>> "news.gmane.org gmane.emacs.devel:237368" nil] 0)))
>>>   gnus-request-article-this-buffer(237368 "gmane.emacs.devel")
>>>   gnus-article-prepare(237368 nil)
>>>   gnus-summary-display-article(237368 nil)
>>>   gnus-summary-select-article(nil nil pseudo)
>>>   gnus-summary-scroll-up(1)
>>>   funcall-interactively(gnus-summary-scroll-up 1)
>>>   call-interactively(gnus-summary-scroll-up nil nil)
>>>   command-execute(gnus-summary-scroll-up)
>>>
>>>
>>> Probably the bisection is useless because this bug was fixed or
>>> superseded by the bug that causes the hang.
>>
>> 40bc7ddb75 works.
>
> f2a7acdde7207f9 is the supposed bad commit, which makes no sense.
>
> Once again, bisecting Emacs turns nothing of value. sigh.
>
> Let's try "human-guided" bisecting.


e188f08fcdb works.

Re: send new reply from gnus hangs

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

>>>>>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>>>>>
>>>>>>> A recent change on the master branch (within the last week) prevents
>>>>>>> gnus from sending replies to newsgroups - it gets stuck with
>>>>>>> "sending..." in the message area.
>>>>>>>
>>>>>>> I've looked at the recent commits that might affect gnus, but nothing
>>>>>>> obvious jumps out. I'm not sure what the problem is or how to start
>>>>>>> debugging it.
>>>>>>>
>>>>>>> Does anyone have any ideas ?
>>>>>>
>>>>>> git bisect

The problematic commit is

master e51adfbdb7587c2b0b5ba154be210b30db82b4ea
Author:     Oleh Krehel <ohwoeowho@gmail.com>
AuthorDate: Thu Jun 6 16:01:10 2019 +0200
Commit:     Oleh Krehel <ohwoeowho@gmail.com>
CommitDate: Thu Jun 6 16:01:10 2019 +0200

Parent:     e188f08fcd lisp/gnus/message.el (message--fold-long-headers): Add docstring
Merged:     emacs-26 master
Containing: master
Follows:    emacs-26.1 (5471)

lisp/gnus/message.el (message--check-continuation-headers): Extract

1 file changed, 13 insertions(+), 21 deletions(-)
lisp/gnus/message.el | 34 +++++++++++++---------------------

modified   lisp/gnus/message.el
@@ -4476,6 +4476,17 @@ message-send-mail-partially
 
 (declare-function hashcash-wait-async "hashcash" (&optional buffer))
 
+(defun message--check-continuation-headers ()
+  (message-check 'continuation-headers
+    (goto-char (point-min))
+    (while (re-search-forward "^[^ \t\n][^ \t\n:]*[ \t\n]" nil t)
+      (goto-char (match-beginning 0))
+      (if (y-or-n-p "Fix continuation lines? ")
+          (insert " ")
+        (forward-line 1)
+        (unless (y-or-n-p "Send anyway? ")
+          (error "Failed to send the message"))))))
+
 (defun message-send-mail (&optional _)
   (require 'mail-utils)
   (let* ((tembuf (message-generate-new-buffer-clone-locals " message temp"))
@@ -4527,15 +4538,7 @@ message-send-mail
 	     (if news nil message-deletable-headers)))
 	(message-generate-headers headers))
       ;; Check continuation headers.
-      (message-check 'continuation-headers
-	(goto-char (point-min))
-	(while (re-search-forward "^[^ \t\n][^ \t\n:]*[ \t\n]" nil t)
-	  (goto-char (match-beginning 0))
-	  (if (y-or-n-p "Fix continuation lines? ")
-	      (insert " ")
-	    (forward-line 1)
-	    (unless (y-or-n-p "Send anyway? ")
-	      (error "Failed to send the message")))))
+      (message--check-continuation-headers)
       (message--fold-long-headers)
       ;; Let the user do all of the above.
       (run-hooks 'message-header-hook))
@@ -5159,18 +5162,7 @@ message-check-news-header-syntax
 	   (if (= (length errors) 1) "this" "these")
 	   (if (= (length errors) 1) "" "s")
 	   (mapconcat 'identity errors ", ")))))))
-   ;; Check continuation headers.
-   (message-check 'continuation-headers
-     (goto-char (point-min))
-     (let ((do-posting t))
-       (while (re-search-forward "^[^ \t\n][^ \t\n:]*[ \t\n]" nil t)
-	 (goto-char (match-beginning 0))
-	 (if (y-or-n-p "Fix continuation lines? ")
-	     (insert " ")
-	   (forward-line 1)
-	   (unless (y-or-n-p "Send anyway? ")
-	     (setq do-posting nil))))
-       do-posting))
+   (message--check-continuation-headers)
    ;; Check the Newsgroups & Followup-To headers for syntax errors.
    (message-check 'valid-newsgroups
      (let ((case-fold-search t)

Re: send new reply from gnus hangs

[Óscar Fuentes]

Confirmed, reverting that commit fixes the problem.

Óscar Fuentes <ofv@wanadoo.es> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>>>>>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>>>>>>
>>>>>>>> A recent change on the master branch (within the last week) prevents
>>>>>>>> gnus from sending replies to newsgroups - it gets stuck with
>>>>>>>> "sending..." in the message area.
>>>>>>>>
>>>>>>>> I've looked at the recent commits that might affect gnus, but nothing
>>>>>>>> obvious jumps out. I'm not sure what the problem is or how to start
>>>>>>>> debugging it.
>>>>>>>>
>>>>>>>> Does anyone have any ideas ?
>>>>>>>
>>>>>>> git bisect
>
> The problematic commit is
>
> master e51adfbdb7587c2b0b5ba154be210b30db82b4ea
> Author:     Oleh Krehel <ohwoeowho@gmail.com>
> AuthorDate: Thu Jun 6 16:01:10 2019 +0200
> Commit:     Oleh Krehel <ohwoeowho@gmail.com>
> CommitDate: Thu Jun 6 16:01:10 2019 +0200
>
> Parent:     e188f08fcd lisp/gnus/message.el (message--fold-long-headers): Add docstring
> Merged:     emacs-26 master
> Containing: master
> Follows:    emacs-26.1 (5471)
>
> lisp/gnus/message.el (message--check-continuation-headers): Extract
>
> 1 file changed, 13 insertions(+), 21 deletions(-)
> lisp/gnus/message.el | 34 +++++++++++++---------------------
>
> modified   lisp/gnus/message.el
> @@ -4476,6 +4476,17 @@ message-send-mail-partially
>  
>  (declare-function hashcash-wait-async "hashcash" (&optional buffer))
>  
> +(defun message--check-continuation-headers ()
> +  (message-check 'continuation-headers
> +    (goto-char (point-min))
> +    (while (re-search-forward "^[^ \t\n][^ \t\n:]*[ \t\n]" nil t)
> +      (goto-char (match-beginning 0))
> +      (if (y-or-n-p "Fix continuation lines? ")
> +          (insert " ")
> +        (forward-line 1)
> +        (unless (y-or-n-p "Send anyway? ")
> +          (error "Failed to send the message"))))))
> +
>  (defun message-send-mail (&optional _)
>    (require 'mail-utils)
>    (let* ((tembuf (message-generate-new-buffer-clone-locals " message temp"))
> @@ -4527,15 +4538,7 @@ message-send-mail
>  	     (if news nil message-deletable-headers)))
>  	(message-generate-headers headers))
>        ;; Check continuation headers.
> -      (message-check 'continuation-headers
> -	(goto-char (point-min))
> -	(while (re-search-forward "^[^ \t\n][^ \t\n:]*[ \t\n]" nil t)
> -	  (goto-char (match-beginning 0))
> -	  (if (y-or-n-p "Fix continuation lines? ")
> -	      (insert " ")
> -	    (forward-line 1)
> -	    (unless (y-or-n-p "Send anyway? ")
> -	      (error "Failed to send the message")))))
> +      (message--check-continuation-headers)
>        (message--fold-long-headers)
>        ;; Let the user do all of the above.
>        (run-hooks 'message-header-hook))
> @@ -5159,18 +5162,7 @@ message-check-news-header-syntax
>  	   (if (= (length errors) 1) "this" "these")
>  	   (if (= (length errors) 1) "" "s")
>  	   (mapconcat 'identity errors ", ")))))))
> -   ;; Check continuation headers.
> -   (message-check 'continuation-headers
> -     (goto-char (point-min))
> -     (let ((do-posting t))
> -       (while (re-search-forward "^[^ \t\n][^ \t\n:]*[ \t\n]" nil t)
> -	 (goto-char (match-beginning 0))
> -	 (if (y-or-n-p "Fix continuation lines? ")
> -	     (insert " ")
> -	   (forward-line 1)
> -	   (unless (y-or-n-p "Send anyway? ")
> -	     (setq do-posting nil))))
> -       do-posting))
> +   (message--check-continuation-headers)
>     ;; Check the Newsgroups & Followup-To headers for syntax errors.
>     (message-check 'valid-newsgroups
>       (let ((case-fold-search t)

Re: send new reply from gnus hangs

[Robert Pluim]

>>>>> On Mon, 10 Jun 2019 01:33:42 +0200, Óscar Fuentes <ofv@wanadoo.es> said:

    Óscar> Confirmed, reverting that commit fixes the problem.

    >> -   ;; Check continuation headers.
    >> -   (message-check 'continuation-headers
    >> -     (goto-char (point-min))
    >> -     (let ((do-posting t))
    >> -       (while (re-search-forward "^[^ \t\n][^ \t\n:]*[ \t\n]" nil t)
    >> -	 (goto-char (match-beginning 0))
    >> -	 (if (y-or-n-p "Fix continuation lines? ")
    >> -	     (insert " ")
    >> -	   (forward-line 1)
    >> -	   (unless (y-or-n-p "Send anyway? ")
    >> -	     (setq do-posting nil))))
    >> -       do-posting))

I guess that function needs an &optional do-posting argument or
similar.

Robert

Re: send new reply from gnus hangs

[Andy Moreton]

On Mon 10 Jun 2019, Óscar Fuentes wrote:

> Confirmed, reverting that commit fixes the problem.
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>> The problematic commit is
>>
>> master e51adfbdb7587c2b0b5ba154be210b30db82b4ea
>> Author:     Oleh Krehel <ohwoeowho@gmail.com>
>> AuthorDate: Thu Jun 6 16:01:10 2019 +0200
>> Commit:     Oleh Krehel <ohwoeowho@gmail.com>
>> CommitDate: Thu Jun 6 16:01:10 2019 +0200

Thanks Óscar, that appears to be the problem.

Looking at that commit, one call site calls `error' to abort sending the
message, so the return value does not matter, but the other uses
do-posting to set the return value from the `check-message' form, which
is used by its caller.

    AndyM

Re: send new reply from gnus hangs

[Eric Abrahamsen]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Mon 10 Jun 2019, Óscar Fuentes wrote:
>
>> Confirmed, reverting that commit fixes the problem.
>>
>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>>
>>> The problematic commit is
>>>
>>> master e51adfbdb7587c2b0b5ba154be210b30db82b4ea
>>> Author:     Oleh Krehel <ohwoeowho@gmail.com>
>>> AuthorDate: Thu Jun 6 16:01:10 2019 +0200
>>> Commit:     Oleh Krehel <ohwoeowho@gmail.com>
>>> CommitDate: Thu Jun 6 16:01:10 2019 +0200
>
> Thanks Óscar, that appears to be the problem.
>
> Looking at that commit, one call site calls `error' to abort sending the
> message, so the return value does not matter, but the other uses
> do-posting to set the return value from the `check-message' form, which
> is used by its caller.

Can I send this followup without hanging?

Re: send new reply from gnus hangs

[Eric Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Mon 10 Jun 2019, Óscar Fuentes wrote:
>
>> Confirmed, reverting that commit fixes the problem.
>>
>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>>
>>> The problematic commit is
>>>
>>> master e51adfbdb7587c2b0b5ba154be210b30db82b4ea
>>> Author:     Oleh Krehel <ohwoeowho@gmail.com>
>>> AuthorDate: Thu Jun 6 16:01:10 2019 +0200
>>> Commit:     Oleh Krehel <ohwoeowho@gmail.com>
>>> CommitDate: Thu Jun 6 16:01:10 2019 +0200
>
> Thanks Óscar, that appears to be the problem.
>
> Looking at that commit, one call site calls `error' to abort sending the
> message, so the return value does not matter, but the other uses
> do-posting to set the return value from the `check-message' form, which
> is used by its caller.
>
>     AndyM

Okay, that worked!

What does everyone think of the attached diff? It moves the
`message-check' call out of the internal function (that seems like work
that should be done by the caller, not the internal function, and helps
the call fit in visually), and either returns nil or errors depending on
an optional arg.

E



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: message-continuation-fix.diff --]
[-- Type: text/x-patch, Size: 2167 bytes --]

diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index 9ce35cece4..012aec0067 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -4477,16 +4477,24 @@ message-send-mail-partially
 
 (declare-function hashcash-wait-async "hashcash" (&optional buffer))
 
-(defun message--check-continuation-headers ()
-  (message-check 'continuation-headers
+(defun message--check-continuation-headers (&optional errorp)
+  "Check for continuation headers and possibly fix.
+Return t if no fixes are necessary.  Prompt the user about fixing
+continuation lines and/or sending without fixing.  If user opts
+not to send, raise an error if ERRORP is non-nil, otherwise
+return nil."
+  (catch 'check
     (goto-char (point-min))
     (while (re-search-forward "^[^ \t\n][^ \t\n:]*[ \t\n]" nil t)
       (goto-char (match-beginning 0))
       (if (y-or-n-p "Fix continuation lines? ")
           (insert " ")
-        (forward-line 1)
-        (unless (y-or-n-p "Send anyway? ")
-          (error "Failed to send the message"))))))
+	(forward-line 1)
+	(unless (y-or-n-p "Send anyway? ")
+	  (if errorp
+              (error "Failed to send the message")
+	    (throw 'check nil)))))
+    t))
 
 (defun message--send-mail-maybe-partially ()
   (if (or (not message-send-mail-partially-limit)
@@ -4571,7 +4579,8 @@ message-send-mail
 	     (if news nil message-deletable-headers)))
 	(message-generate-headers headers))
       ;; Check continuation headers.
-      (message--check-continuation-headers)
+      (message-check 'continuation-headers
+	(message--check-continuation-headers 'error))
       (message--fold-long-headers)
       ;; Let the user do all of the above.
       (run-hooks 'message-header-hook))
@@ -5166,7 +5175,8 @@ message-check-news-header-syntax
 	   (if (= (length errors) 1) "this" "these")
 	   (if (= (length errors) 1) "" "s")
 	   (mapconcat 'identity errors ", ")))))))
-   (message--check-continuation-headers)
+   (message-check 'continuation-headers
+     (message--check-continuation-headers))
    ;; Check the Newsgroups & Followup-To headers for syntax errors.
    (message-check 'valid-newsgroups
      (let ((case-fold-search t)

Re: send new reply from gnus hangs

[Óscar Fuentes]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Okay, that worked!
>
> What does everyone think of the attached diff? It moves the
> `message-check' call out of the internal function (that seems like work
> that should be done by the caller, not the internal function, and helps
> the call fit in visually), and either returns nil or errors depending on
> an optional arg.

I have no time now to review the code (and I'm not familiar with Gnus'
code base) but I was going to propose reverting the problematic commit.
If your patch solves the problem, great. If there are doubts, the right
thing is reverting.

There is no justification for having master in an unusable state (if you
are a Gnus user) for more than a week due to a cosmetic change like
this.

Re: send new reply from gnus hangs

[Eric Abrahamsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Okay, that worked!
>>
>> What does everyone think of the attached diff? It moves the
>> `message-check' call out of the internal function (that seems like work
>> that should be done by the caller, not the internal function, and helps
>> the call fit in visually), and either returns nil or errors depending on
>> an optional arg.
>
> I have no time now to review the code (and I'm not familiar with Gnus'
> code base) but I was going to propose reverting the problematic commit.
> If your patch solves the problem, great. If there are doubts, the right
> thing is reverting.
>
> There is no justification for having master in an unusable state (if you
> are a Gnus user) for more than a week due to a cosmetic change like
> this.

Stefan's already fixed this with a different patch, it should be working
again now.