bug#45944: 28.0.50; Mailabbrev sometimes hangs

bug#45944: 28.0.50; Mailabbrev sometimes hangs

[Katsumi Yamaoka]

Hi,

When expanding a mail abbrev in the message header of a message-
mode buffer, it sometime hangs like it goes into an infinite loop.
It's ok for Emacs on the Linux platform because I can break it by
C-g.  However, on Cygwin, only I can do is to kill Emacs, as C-g
doesn't break a Lisp infinite loop on Emacs built on that platform.

Though I haven't found out the cause of the problem so far, it seems
to happen when there are some kinds of contents in the message body,
and seems not to happen if the body is empty.  So, a workaround I'm
using now is as follows:

(defadvice abbrev--default-expand (around my-narrow-to-head activate)
  "Narrow the messge buffer to the headers when expanding an abbrev."
  (save-restriction
    (when (message-point-in-header-p)
      (let ((cur (point)))
        (message-narrow-to-headers)
        (goto-char cur)))
    ad-do-it))

Thanks.

bug#45944: 28.0.50; Mailabbrev sometimes hangs

[Katsumi Yamaoka]

On Mon, 18 Jan 2021 09:10:31 +0900, Katsumi Yamaoka wrote:
> When expanding a mail abbrev in the message header of a message-
> mode buffer, it sometime hangs like it goes into an infinite loop.
[...]
> Though I haven't found out the cause of the problem so far,...

I found it.  `(forward-word 1)' in the `abbrev--before-point'
function takes a very long time for a certain mail body contents
(`hang' I wrote first was my misregarding).
Here is a recipe to reproduce the problem in `emacs -Q':

1. Create the ~/.mailrc file, if it is absent.
   The file needs to contain at least a line like this:

--8<---------------cut here---------------start------------->8---
foo foo@example.com.invalid
--8<---------------cut here---------------end--------------->8---

2. Eval this form in the *scratch* buffer.

--8<---------------cut here---------------start------------->8---
(with-current-buffer (get-buffer-create "*testing*")
  (erase-buffer)
  (insert "To: \n--text follows this line--\n\
________________________________________________________________\n")
  (message-mode)
  (mail-abbrevs-setup)
  (goto-char (point-min))
  (end-of-line)
  (pop-to-buffer (current-buffer)))
--8<---------------cut here---------------end--------------->8---

3. In To: header, enter "foo" or something another and type ",".


As far as I can observe, the more "____" line is long, the more
it takes a long time.

Thanks.

bug#45944: 28.0.50; Mailabbrev sometimes hangs

[Lars Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> As far as I can observe, the more "____" line is long, the more
> it takes a long time.

Curious.  I can reproduce this with the example code, but the function
that's hanging is apparently just doing:

(re-search-forward (concat "^" mail-citation-prefix-regexp ".*$") nil t)

When I try this manually, then it doesn't hang, which is the curious
thing?  So why is it hanging from a syntax-propertize perspective but
not when called directly?

Debugger entered--Lisp error: (quit)
  search-forward-regexp("^\\([ \11]*\\(\\w\\|[_.]\\)+>+\\|[ \11]*[>|]\\)+.*$" 100 noerror)
  (while (search-forward-regexp citation-regexp end 'noerror) (let ((
  (let ((citation-regexp (concat "^" message-cite-prefix-regexp ".*$"
  message--syntax-propertize(1 100)
  syntax-propertize(100)
  internal--syntax-propertize(7)
  abbrev--before-point()

Anyway, this is the regexp in question:

(defcustom mail-citation-prefix-regexp
  (purecopy "\\([ \t]*\\(\\w\\|[_.]\\)+>+\\|[ \t]*[>|]\\)+")

And I guess there's some extreme backtracking going on with the

  \\(\\w\\|[_.]\\)+>

part?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45944: 28.0.50; Mailabbrev sometimes hangs

[Andreas Schwab]

On Jan 19 2021, Lars Ingebrigtsen wrote:

> And I guess there's some extreme backtracking going on with the
>
>   \\(\\w\\|[_.]\\)+>
>
> part?

Does `\w' match `_'?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#45944: 28.0.50; Mailabbrev sometimes hangs

[Katsumi Yamaoka]

Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Jan 19 2021, Lars Ingebrigtsen wrote:
>> And I guess there's some extreme backtracking going on with the
>>   \\(\\w\\|[_.]\\)+>
>> part?
> Does `\w' match `_'?

Yes it does.  While the hang arises, syntax table is overridden
temporarily with `mail-abbrev-syntax-table'.

(mail-abbrev-make-syntax-table)
(with-syntax-table mail-abbrev-syntax-table
  (string-match "\\w" "_"))

So, it explains some strange things, doesn't it?  Actually, this
advice looks to solve the problem:

(defadvice message--syntax-propertize (around use-standard-syntax-table
                                              activate)
  "Use standard-syntax-table."
  (with-syntax-table (standard-syntax-table)
    ad-do-it))

bug#45944: 28.0.50; Mailabbrev sometimes hangs

[Lars Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Yes it does.  While the hang arises, syntax table is overridden
> temporarily with `mail-abbrev-syntax-table'.
>
> (mail-abbrev-make-syntax-table)
> (with-syntax-table mail-abbrev-syntax-table
>   (string-match "\\w" "_"))
>
> So, it explains some strange things, doesn't it?  Actually, this
> advice looks to solve the problem:
>
> (defadvice message--syntax-propertize (around use-standard-syntax-table
>                                               activate)
>   "Use standard-syntax-table."
>   (with-syntax-table (standard-syntax-table)
>     ad-do-it))

I've now changed the function along these lines -- it now starts with

(defun message--syntax-propertize (beg end)
  "Syntax-propertize certain message text specially."
  (with-syntax-table message-mode-syntax-table

and this seems to fix the reported test case.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45944: 28.0.50; Mailabbrev sometimes hangs

[Katsumi Yamaoka]

On Tue, 19 Jan 2021 16:09:28 +0100, Lars Ingebrigtsen wrote:
> I've now changed the function along these lines -- it now starts with

> (defun message--syntax-propertize (beg end)
>   "Syntax-propertize certain message text specially."
>   (with-syntax-table message-mode-syntax-table

> and this seems to fix the reported test case.

Good!  This fixes the problem that arises when manipulating the
header of a reply message to the actual email I first found it.
Thanks.  Closing.