GNU bug report logs - #17281
24.4.50; emacs hangs in next-line

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17281 in the body.
You can then email your comments to 17281 AT debbugs.gnu.org in the normal way.

the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 08:10:37 +0200

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 <at> 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.

Message #8 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
Cc: 17281 <at> debbugs.gnu.org
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 10:13:02 +0300

> Date: 2014年4月17日 08:10:37 +0200
> From: "Stefan-W. Hahn" <stefan.hahn <at> 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?

Message #11 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17281 <at> debbugs.gnu.org
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 09:25:23 +0200

Mail von Eli Zaretskii, 2014年4月17日 at 10:13:02 +0300:
> > Date: 2014年4月17日 08:10:37 +0200
> > From: "Stefan-W. Hahn" <stefan.hahn <at> 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 <at> 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.

Message #14 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
Cc: 17281 <at> debbugs.gnu.org
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 11:00:05 +0300

> Date: 2014年4月17日 09:25:23 +0200
> From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
> Cc: 17281 <at> debbugs.gnu.org
> 
> Mail von Eli Zaretskii, 2014年4月17日 at 10:13:02 +0300:
> > > Date: 2014年4月17日 08:10:37 +0200
> > > From: "Stefan-W. Hahn" <stefan.hahn <at> 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 <at> 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).

Message #17 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17281 <at> debbugs.gnu.org
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 10:29:31 +0200

Mail von Eli Zaretskii, 2014年4月17日 at 11:00:05 +0300:
> > Date: 2014年4月17日 09:25:23 +0200
> > From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
> > Cc: 17281 <at> 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.

Message #20 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
Cc: 17281 <at> debbugs.gnu.org
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 12:03:03 +0300

> Date: 2014年4月17日 10:29:31 +0200
> From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
> Cc: 17281 <at> debbugs.gnu.org
> 
> Mail von Eli Zaretskii, 2014年4月17日 at 11:00:05 +0300:
> > > Date: 2014年4月17日 09:25:23 +0200
> > > From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
> > > Cc: 17281 <at> 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

Message #23 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: stefan.hahn <at> s-hahn.de, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17281 <at> debbugs.gnu.org
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 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.
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.

Message #26 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17281 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 13:00:47 +0200

Mail von Eli Zaretskii, 2014年4月17日 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.

Message #29 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
Cc: 17281 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 14:25:40 +0300

> Date: 2014年4月17日 13:00:47 +0200
> From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 17281 <at> debbugs.gnu.org
> 
> Mail von Eli Zaretskii, 2014年4月17日 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?

Message #32 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17281 <at> debbugs.gnu.org, stefan.hahn <at> s-hahn.de
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 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.
 Stefan

Message #35 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
Cc: 17281 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 08:39:36 -0400

> 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

Message #38 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 17281 <at> debbugs.gnu.org, stefan.hahn <at> s-hahn.de
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 15:47:58 +0300

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: stefan.hahn <at> s-hahn.de, 17281 <at> debbugs.gnu.org
> Date: 2014年4月17日 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.

Message #41 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17281 <at> debbugs.gnu.org
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 14:56:37 +0200

Mail von Eli Zaretskii, 2014年4月17日 at 12:03:03 +0300:
> > Date: 2014年4月17日 10:29:31 +0200
> > From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
> > Cc: 17281 <at> debbugs.gnu.org
> > 
> > Mail von Eli Zaretskii, 2014年4月17日 at 11:00:05 +0300:
> > > > Date: 2014年4月17日 09:25:23 +0200
> > > > From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
> > > > Cc: 17281 <at> 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.

Message #46 received at 17281-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
Cc: 17281-done <at> debbugs.gnu.org
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 16:13:22 +0300

> Date: 2014年4月17日 14:56:37 +0200
> From: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>
> Cc: 17281 <at> 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.

Message #49 received at 17281 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17281 <at> debbugs.gnu.org, stefan.hahn <at> s-hahn.de
Subject: Re: bug#17281: 24.4.50; emacs hangs in next-line
Date: 2014年4月17日 09:16:15 -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.
Yes, that's perfectly fine, thank you,
 Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.