bug#17281: 24.4.50; emacs hangs in next-line

bug#17281: 24.4.50; emacs hangs in next-line

[Stefan-W. Hahn]

In GNU Emacs 24.4.50.2 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2014-03-31 on pille

commit 79bbb1454f3e44bf69096f03c26bb42f4930e591

If loading a mail from mutt with emacsclient and emacs is in an org-mode
file, emacs hangs. I use

;	$Id: post.el,v 1.10 2008/02/24 23:49:23 rreid Exp $
;; post.el --- Use (X?)Emacs(client) as an external editor for mail and news.

to colorize my mutt mails.

Stripping this down it seems, that (next-line) is the problem.
I have made following simple mode:

#+BEGIN_SRC: elisp "next-line.el"
(defun test ()
  (interactive)
  (goto-char (point-min))
  (save-match-data (re-search-forward "^$" nil t))
  (next-line 1))

(require 'derived)
(define-derived-mode test-mode text-mode "Test"
  ""
  (test))
#+END_SRC

#+BEGIN_SRC: "mutt-test"
-*- mode: test; -*-
From: my-address@xxx.org
To: 
Cc: 
Bcc: 
Subject: 
Reply-To: 
Organization: -no organization-
X-GPG-Fingerprint: 0xE4FCD563 / EF09 97BB 3731 7DC7 25BA 5C39 185C F986 E4FC
 D56


-- 
my-address
#+END_SRC

If I now do the following, emacs hangs:

- start "emacs -Q"
- load next-line.el
- eval-buffer
- load test-neuter.org (big org-mode file)
- load mutt-test

If I remove the line " D56" in mutt-test, than emacs does not hang.


Here is my configuration output from report-emacs-bugs:

Windowing system distributor `The X.Org Foundation', version 11.0.11204000
System Description:	Debian GNU/Linux 7.4 (wheezy)

Configured using:
 `configure --prefix=/opt/emacs24'

Configured features:
XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB

Important settings:
  value of $LC_COLLATE: de_DE.UTF-8
  value of $LC_CTYPE: de_DE.UTF-8
  value of $LC_MESSAGES: en_GB.UTF8
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> M-x b u g s <tab> <backspace> 
<backspace> <backspace> <backspace> e m a c s - <tab> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> r e p o r r t - <backspace> <backspace> 
<backspace> t - <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 8 75924 4097)
 (symbols 24 17699 0)
 (miscs 20 37 148)
 (strings 16 10600 3890)
 (string-bytes 1 288533)
 (vectors 8 9808)
 (vector-slots 4 382981 1800)
 (floats 8 64 65)
 (intervals 28 226 30)
 (buffers 512 13)
 (heap 1024 14126 551))

With kind regards
Stefan

-- 
Stefan-W. Hahn                          It is easy to make things.
                                        It is hard to make things simple.

bug#17281: 24.4.50; emacs hangs in next-line

[Eli Zaretskii]

> Date: Thu, 17 Apr 2014 08:10:37 +0200
> From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> 
> In GNU Emacs 24.4.50.2 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
>  of 2014-03-31 on pille
> 
> commit 79bbb1454f3e44bf69096f03c26bb42f4930e591

Thanks for the report, but please don't cite git sha1 values alone to
specify a commit; please show the full commit log message instead.  As
long as we use bzr as the primary VCS, git sha values don't bring
enough information to identify a commit, not without some extra work.

> Stripping this down it seems, that (next-line) is the problem.

Sounds like another duplicate of 17269.  Does setting cache-long-scans
to nil solve the problem?

bug#17281: 24.4.50; emacs hangs in next-line

[Stefan-W. Hahn]

Mail von Eli Zaretskii, Thu, 17 Apr 2014 at 10:13:02 +0300:
> > Date: Thu, 17 Apr 2014 08:10:37 +0200
> > From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> > 
> > In GNU Emacs 24.4.50.2 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
> >  of 2014-03-31 on pille
> > 
> > commit 79bbb1454f3e44bf69096f03c26bb42f4930e591
> 
> Thanks for the report, but please don't cite git sha1 values alone to
> specify a commit; please show the full commit log message instead.  As
> long as we use bzr as the primary VCS, git sha values don't bring
> enough information to identify a commit, not without some extra work.

Sorry,

commit 79bbb1454f3e44bf69096f03c26bb42f4930e591
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Mon Mar 31 11:13:58 2014 +0400

    * search.c (Freplace_match): Use make_specified_string.
    * xterm.c, w32term.c (x_set_glyph_string_gc): Use emacs_abort
    to catch bogus override face of glyph strings.

> 
> > Stripping this down it seems, that (next-line) is the problem.
> 
> Sounds like another duplicate of 17269.  Does setting cache-long-scans
> to nil solve the problem?

No it does not solve it.

With kind regards,
Stefan

-- 
Stefan-W. Hahn                          It is easy to make things.
                                        It is hard to make things simple.

bug#17281: 24.4.50; emacs hangs in next-line

[Eli Zaretskii]

> Date: Thu, 17 Apr 2014 09:25:23 +0200
> From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> Cc: 17281@debbugs.gnu.org
> 
> Mail von Eli Zaretskii, Thu, 17 Apr 2014 at 10:13:02 +0300:
> > > Date: Thu, 17 Apr 2014 08:10:37 +0200
> > > From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> > > 
> > > In GNU Emacs 24.4.50.2 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
> > >  of 2014-03-31 on pille
> > > 
> > > commit 79bbb1454f3e44bf69096f03c26bb42f4930e591
> > 
> > Thanks for the report, but please don't cite git sha1 values alone to
> > specify a commit; please show the full commit log message instead.  As
> > long as we use bzr as the primary VCS, git sha values don't bring
> > enough information to identify a commit, not without some extra work.
> 
> Sorry,
> 
> commit 79bbb1454f3e44bf69096f03c26bb42f4930e591
> Author: Dmitry Antipov <dmantipov@yandex.ru>
> Date:   Mon Mar 31 11:13:58 2014 +0400
> 
>     * search.c (Freplace_match): Use make_specified_string.
>     * xterm.c, w32term.c (x_set_glyph_string_gc): Use emacs_abort
>     to catch bogus override face of glyph strings.

Thanks.

> > > Stripping this down it seems, that (next-line) is the problem.
> > 
> > Sounds like another duplicate of 17269.  Does setting cache-long-scans
> > to nil solve the problem?
> 
> No it does not solve it.

Then it's a different bug.  Are you sure it didn't happen before the
above commit?  I seem to be able to reproduce it as far back as Mar 15
(I have no easy way of trying older versions, due to changes in Lisp
files involved in this recipe).

bug#17281: 24.4.50; emacs hangs in next-line

[Stefan-W. Hahn]

Mail von Eli Zaretskii, Thu, 17 Apr 2014 at 11:00:05 +0300:
> > Date: Thu, 17 Apr 2014 09:25:23 +0200
> > From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> > Cc: 17281@debbugs.gnu.org
> > 
> Then it's a different bug.  Are you sure it didn't happen before the
> above commit?  I seem to be able to reproduce it as far back as Mar 15
> (I have no easy way of trying older versions, due to changes in Lisp
> files involved in this recipe).

I tried it back till 17. Dec 2013, but not all versions are compileable.
All tried vesions have the same problem.

I even tried to debug it and I came to line-pixel-height (xdisp.c), which
calls start-display(). I made a debug output in line-pixel-height before the
call to start_display() and after. In the problematic case I never saw the
debug output after start_display().

With kind regards,
Stefan

-- 
Stefan-W. Hahn                          It is easy to make things.
                                        It is hard to make things simple.

bug#17281: 24.4.50; emacs hangs in next-line

[Eli Zaretskii]

> Date: Thu, 17 Apr 2014 10:29:31 +0200
> From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> Cc: 17281@debbugs.gnu.org
> 
> Mail von Eli Zaretskii, Thu, 17 Apr 2014 at 11:00:05 +0300:
> > > Date: Thu, 17 Apr 2014 09:25:23 +0200
> > > From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> > > Cc: 17281@debbugs.gnu.org
> > > 
> > Then it's a different bug.  Are you sure it didn't happen before the
> > above commit?  I seem to be able to reproduce it as far back as Mar 15
> > (I have no easy way of trying older versions, due to changes in Lisp
> > files involved in this recipe).
> 
> I tried it back till 17. Dec 2013, but not all versions are compileable.
> All tried vesions have the same problem.
> 
> I even tried to debug it and I came to line-pixel-height (xdisp.c), which
> calls start-display(). I made a debug output in line-pixel-height before the
> call to start_display() and after. In the problematic case I never saw the
> debug output after start_display().

The infloop was indeed inside line-pixel-height.  Please try the patch
below, which I just committed to the emacs-24 branch.  It fixes your
recipe, so I hope the original use case with emacsclient will also be
fixed.

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2014-04-12 11:21:47 +0000
+++ src/xdisp.c	2014-04-17 08:58:59 +0000
@@ -1262,12 +1262,23 @@ Value is the height in pixels of the lin
   struct it it;
   struct text_pos pt;
   struct window *w = XWINDOW (selected_window);
+  struct buffer *old_buffer = NULL;
+  Lisp_Object result;
 
+  if (XBUFFER (w->contents) != current_buffer)
+    {
+      old_buffer = current_buffer;
+      set_buffer_internal_1 (XBUFFER (w->contents));
+    }
   SET_TEXT_POS (pt, PT, PT_BYTE);
   start_display (&it, w, pt);
   it.vpos = it.current_y = 0;
   last_height = 0;
-  return make_number (line_bottom_y (&it));
+  result = make_number (line_bottom_y (&it));
+  if (old_buffer)
+    set_buffer_internal_1 (old_buffer);
+
+  return result;
 }
 
 /* Return the default pixel height of text lines in window W.  The

bug#17281: 24.4.50; emacs hangs in next-line

[Eli Zaretskii]

Btw, just FYI, this code:

  (defun test ()
    (interactive)
    (goto-char (point-min))
    (save-match-data (re-search-forward "^$" nil t))
    (next-line 1))

doesn't do what you think.  next-line does TRT for the selected
window, but in this case the mode function 'test' runs when the buffer
that visits the file is not yet displayed in any window, certainly not
in the selected one.  You want to call forward-line instead.

Stefan (Monnier), this raises a general issue with next-line: is it
supposed to work accurately in a buffer that is not the currently
selected window's buffer?  If so, the call to line-pixel-height should
be made after switching to the current buffer in the selected window.
Right now, line-pixel-height returns its result computed for the
selected window, which is OK when next-line is invoked interactively,
but not if it is part of some non-interactive code, such as the mode
function in this case.

bug#17281: 24.4.50; emacs hangs in next-line

[Stefan-W. Hahn]

Mail von Eli Zaretskii, Thu, 17 Apr 2014 at 13:16:52 +0300:
> Btw, just FYI, this code:
> 
>   (defun test ()
>     (interactive)
>     (goto-char (point-min))
>     (save-match-data (re-search-forward "^$" nil t))
>     (next-line 1))
> 
> doesn't do what you think.  next-line does TRT for the selected
> window, but in this case the mode function 'test' runs when the buffer
> that visits the file is not yet displayed in any window, certainly not
> in the selected one.  You want to call forward-line instead.

Thx.

It's just an excerpt from

;	$Id: post.el,v 1.10 2008/02/24 23:49:23 rreid Exp $
;; post.el --- Use (X?)Emacs(client) as an external editor for mail and news.

#+BEGIN_SRC elisp
(defun post-goto-body ()
  "Go to the beginning of the message body."
  (interactive)
  (goto-char (point-min))
  ;; If the message has header, slide downward.
  (and header-mode (save-match-data (re-search-forward "^$" nil t))
       (next-line 1))
  )
#+END_SRC

Is there a better mode for writing emails (I use mutt calling emacs for
that).

With kind regards,
Stefan

-- 
Stefan-W. Hahn                          It is easy to make things.
                                        It is hard to make things simple.

bug#17281: 24.4.50; emacs hangs in next-line

[Eli Zaretskii]

> Date: Thu, 17 Apr 2014 13:00:47 +0200
> From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 17281@debbugs.gnu.org
> 
> Mail von Eli Zaretskii, Thu, 17 Apr 2014 at 13:16:52 +0300:
> > Btw, just FYI, this code:
> > 
> >   (defun test ()
> >     (interactive)
> >     (goto-char (point-min))
> >     (save-match-data (re-search-forward "^$" nil t))
> >     (next-line 1))
> > 
> > doesn't do what you think.  next-line does TRT for the selected
> > window, but in this case the mode function 'test' runs when the buffer
> > that visits the file is not yet displayed in any window, certainly not
> > in the selected one.  You want to call forward-line instead.
> 
> Thx.
> 
> It's just an excerpt from
> 
> ;	$Id: post.el,v 1.10 2008/02/24 23:49:23 rreid Exp $
> ;; post.el --- Use (X?)Emacs(client) as an external editor for mail and news.
> 
> #+BEGIN_SRC elisp
> (defun post-goto-body ()
>   "Go to the beginning of the message body."
>   (interactive)
>   (goto-char (point-min))
>   ;; If the message has header, slide downward.
>   (and header-mode (save-match-data (re-search-forward "^$" nil t))
>        (next-line 1))
>   )
> #+END_SRC

If this function can be invoked when the message is not displayed in
the currently selected window, next-line will not work correctly,
because it assumes it's invoked in the selected window.  (It will
still do a perfect job in many cases, though, as long as the selected
window doesn't use any fonts or faces that significantly change the
size of the current line.)

> Is there a better mode for writing emails (I use mutt calling emacs for
> that).

There are many ways of using Emacs for email, but that's tangential to
the issue at point.

Is the original problem solved by the patch I showed?

bug#17281: 24.4.50; emacs hangs in next-line

[Stefan Monnier]

> Stefan (Monnier), this raises a general issue with next-line: is it
> supposed to work accurately in a buffer that is not the currently
> selected window's buffer?

No.


        Stefan

bug#17281: 24.4.50; emacs hangs in next-line

[Stefan Monnier]

> It's just an excerpt from
[...]
> ;; post.el --- Use (X?)Emacs(client) as an external editor for mail and news.
[...]
>        (next-line 1))

C-h f next-line:

   [...]
   This function is for interactive use only;
   in Lisp code use `forward-line' instead.
   [...]

I.e. please report this to post.el's maintainers.


        Stefan

bug#17281: 24.4.50; emacs hangs in next-line

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: stefan.hahn@s-hahn.de, 17281@debbugs.gnu.org
> Date: Thu, 17 Apr 2014 08:37:45 -0400
> 
> > Stefan (Monnier), this raises a general issue with next-line: is it
> > supposed to work accurately in a buffer that is not the currently
> > selected window's buffer?
> 
> No.

OK, then the fix in line-pixel-height I committed to prevent it from
inflooping should be good enough.  Those who use next-line from a
buffer that is not in the selected window will simply get a value from
a potentially different buffer.

bug#17281: 24.4.50; emacs hangs in next-line

[Stefan-W. Hahn]

Mail von Eli Zaretskii, Thu, 17 Apr 2014 at 12:03:03 +0300:
> > Date: Thu, 17 Apr 2014 10:29:31 +0200
> > From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> > Cc: 17281@debbugs.gnu.org
> > 
> > Mail von Eli Zaretskii, Thu, 17 Apr 2014 at 11:00:05 +0300:
> > > > Date: Thu, 17 Apr 2014 09:25:23 +0200
> > > > From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> > > > Cc: 17281@debbugs.gnu.org
> > > > 
> > > Then it's a different bug.  Are you sure it didn't happen before the
> > > above commit?  I seem to be able to reproduce it as far back as Mar 15
> > > (I have no easy way of trying older versions, due to changes in Lisp
> > > files involved in this recipe).
> > 
> > I tried it back till 17. Dec 2013, but not all versions are compileable.
> > All tried vesions have the same problem.
> > 
> > I even tried to debug it and I came to line-pixel-height (xdisp.c), which
> > calls start-display(). I made a debug output in line-pixel-height before the
> > call to start_display() and after. In the problematic case I never saw the
> > debug output after start_display().
> 
> The infloop was indeed inside line-pixel-height.  Please try the patch
> below, which I just committed to the emacs-24 branch.  It fixes your
> recipe, so I hope the original use case with emacsclient will also be
> fixed.

Yes your patch fixes the problem in the stripped down case and also in my
use case with mutt.

Thanks for your quick response.

P.S. "make bootstrap" did the trick to build emacs.

With kind regards,
Stefan

-- 
Stefan-W. Hahn                          It is easy to make things.
                                        It is hard to make things simple.

bug#17281: 24.4.50; emacs hangs in next-line

[Eli Zaretskii]

> Date: Thu, 17 Apr 2014 14:56:37 +0200
> From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> Cc: 17281@debbugs.gnu.org
> 
> > The infloop was indeed inside line-pixel-height.  Please try the patch
> > below, which I just committed to the emacs-24 branch.  It fixes your
> > recipe, so I hope the original use case with emacsclient will also be
> > fixed.
> 
> Yes your patch fixes the problem in the stripped down case and also in my
> use case with mutt.
> 
> Thanks for your quick response.

Great, closing.

bug#17281: 24.4.50; emacs hangs in next-line

[Stefan Monnier]

>> > Stefan (Monnier), this raises a general issue with next-line: is it
>> > supposed to work accurately in a buffer that is not the currently
>> > selected window's buffer?
>> No.
> OK, then the fix in line-pixel-height I committed to prevent it from
> inflooping should be good enough.

Yes, that's perfectly fine, thank you,


        Stefan