|
From: | GNU bug Tracking System |
Subject: | [debbugs-tracker] bug#16129: closed (24.3.50; Emacs slow with follow-mode when buffer ends before last window) |
Date: | Mon, 06 Jan 2014 16:34:02 +0000 |
Your message dated Mon, 06 Jan 2014 18:33:02 +0200 with message-id <address@hidden> and subject line Re: bug#16129: 24.3.50; Emacs slow with follow-mode when buffer ends before last window has caused the debbugs.gnu.org bug report #16129, regarding 24.3.50; Emacs slow with follow-mode when buffer ends before last window to be marked as done. (If you believe you have received this mail in error, please contact address@hidden) -- 16129: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16129 GNU Bug Tracking System Contact address@hidden with problems
--- Begin Message ---Subject: 24.3.50; Emacs slow with follow-mode when buffer ends before last window Date: Fri, 13 Dec 2013 15:34:07 +0100 When follow-mode is enabled and the displayed buffer ends before the last window, Emacs becomes extremely slow.This broke on revision 115272 (see log below).Steps to repeat the problem:emacs -QC-u 10 RETC-x 3M-x follow-mode RETHere, moving the cursor up or down one line takes about one second. Holding and the arrow keys cause the cursor to disappear until the key is released or the edge of the buffer has been reached.The problem disappears as soon as some parts of the buffer is shown in the rightmost window.I am the original author of follow-mode, so I can share one interesting implementation detail. When the viewed buffer ends before the last window, follow-mode tries to display this window without any content (by setting the window start to point-max). Unfortunately, the Emacs display engine always tries ensure that windows are not empty so it repositions it... So, follow-mode hammers in its view of the world every chance it gets, currrently in post-command hook and window-scroll-functions.
Sincerely,Anders LindgrenPs. Log for revision 115272:revno: 115272
committer: Stefan Monnier <address@hidden>
branch nick: trunk
timestamp: Thu 2013-11-28 17:43:09 -0500
message:
Refine redisplay optimizations to only redisplay *some* frames/windows
rather than all of them.
* src/xdisp.c (REDISPLAY_SOME): New constant.
(redisplay_other_windows, wset_redisplay, fset_redisplay)
(bset_redisplay, bset_update_mode_line): New functions.
(message_dolog): Use bset_redisplay.
(clear_garbaged_frames): Use fset_redisplay.
(echo_area_display): Use wset_redisplay.
(buffer_shared_and_changed): Remove.
(prepare_menu_bars): Call Vpre_redisplay_function before updating
frame titles. Compute the actual set of windows redisplayed.
Don't update frame titles and menu bars for frames that don't need to
be redisplayed.
(propagate_buffer_redisplay): New function.
(AINC): New macro.
(redisplay_internal): Use it. Be more selective in the set of windows
we redisplay. Propagate windows_or_buffers_changed to
update_mode_lines a bit later to simplify the code.
(mark_window_display_accurate_1): Reset window and buffer's
`redisplay' flag.
(redisplay_window): Do nothing if neither the window nor the buffer nor
the frame needs redisplay.
* src/window.h (struct window): Add `redisplay' field.
(wset_redisplay, fset_redisplay, bset_redisplay, bset_update_mode_line)
(redisplay_other_windows, window_list): New declarations.
* src/window.c (select_window, Fset_window_start): Use wset_redisplay.
(window_list): Not static any more.
(grow_mini_window, shrink_mini_window): Use fset_redisplay.
* src/minibuf.c (read_minibuf_unwind): Don't redisplay everything.
* src/insdel.c (prepare_to_modify_buffer_1): Use bset_redisplay.
* src/frame.c (Fmake_frame_visible): Don't redisplay everything.
* src/frame.h (struct frame): Add `redisplay' field.
Move `external_menu_bar' bitfield next to other bit-fields.
(SET_FRAME_GARBAGED): Use fset_redisplay.
(SET_FRAME_VISIBLE): Don't garbage the frame;
Use redisplay_other_windows.
* src/buffer.h (struct buffer): Add `redisplay' field.
* src/buffer.c (Fforce_mode_line_update): Pay attention to the `all' flag.
(modify_overlay): Use bset_redisplay.
* src/alloc.c (gc_sweep): Don't unmark strings while sweeping symbols.
* lisp/doc-view.el (doc-view-goto-page): Update mode-line.
In GNU Emacs 24.3.50.1 (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00)of 2013-12-13 on macpro.lanBzr revision: 115272 address@hiddenWindowing system distributor `Apple', version 10.3.1265Configured using:`configure --with-ns'Important settings:value of $LC_CTYPE: UTF-8locale-coding-system: utf-8-unixdefault enable-multibyte-characters: tMajor mode: Lisp InteractionMinor modes in effect:follow-mode: ttooltip-mode: tmouse-wheel-mode: ttool-bar-mode: tmenu-bar-mode: tfile-name-shadow-mode: tglobal-font-lock-mode: tfont-lock-mode: tblink-cursor-mode: tauto-composition-mode: tauto-encryption-mode: tauto-compression-mode: tline-number-mode: ttransient-mark-mode: tRecent input:<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up><up> <down> <down> <down> <down> <down> <down> <down><down> <down> <down> <down> <down> <down> <down> <down>C-x 3 <up> <up> <up> <up> <up> <up> <up> <up> <escape>x f o l l o w - d e <backspace> <backspace> m o d e<return> <up> <up> <up> <up> <up> <up> <up> <up> <up><up> <down> <down> <down> <down> <down> <down> <down><down> <down> <down> <down> <down> <down> <down> <down><down> <down> <down> <down> <down> <down> <down> <down><down> <down> <down> <down> <up> <up> <up> <up> <up><up> <up> <up> <up> <up> C-h v e m a c s - b z <tab><return> <up> <up> <up> <up> <up> <up> <up> <up> <down><down> <down> <down> <down> <down> <down> <down> <down><down> <down> <down> <down> <down> <down> <down> <down><down> <up> <up> <up> <up> <up> <up> C-x o C-x b *s c <tab> <return> <up> <up> <up> <up> <up> <up> <up><up> <up> <up> <up> <up> <up> <up> <down> <down> C-x1 <down> <down> <down> <down> <down> <down> <down><down> <down> <menu-bar> <help-menu> <send-emacs-bug-report>F o l l o w - m o d e SPC s <backspace> i s SPC <backspace><backspace> <backspace> <backspace> <backspace> <backspace><backspace> <backspace> <backspace> <backspace> <backspace><backspace> <backspace> <backspace> <backspace> R ed i d <backspace> <backspace> <backspace> <backspace><backspace> E m a c s SPC i s SPC s l o w SPC w h en SPC f o l l o w - m o d e SPC i s SPC a <backspace>e n a b l e d SPC a n d SPC b u f f e r SPC t a i lC-a <right> <right> <right> <right> <right> <right><right> <right> <right> <s-backspace> <menu-bar> <help-menu><send-emacs-bug-report>Recent messages:Beginning of bufferEnd of bufferFollow mode enabledBeginning of buffer [4 times]End of buffer [13 times]Type "q" in help window to restore its previous buffer.Beginning of buffer [4 times]End of buffer [4 times]Beginning of buffer [6 times]<s-backspace> is undefinedQuitLoad-path shadows:None found.Features:(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mmlmml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrevgmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-utilmail-prsvr mail-utils pp help-mode help-fns follow easymenu time-datetooltip ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dndfontset image regexp-opt fringe tabulated-list newcomment lisp-modeprog-mode register page menu-bar rfn-eshadow timer select scroll-barmouse jit-lock font-lock syntax facemenu font-core frame cham georgianutf-8-lang misc-lang vietnamese tibetan thai tai-viet lao koreanjapanese hebrew greek romanian slovak czech european ethiopic indiancyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrevminibuffer nadvice loaddefs button faces cus-face macroexp filestext-properties overlay sha1 md5 base64 format env code-pages mulecustom widget hashtable-print-readable backquote make-network-processcocoa ns multi-tty emacs)
--- End Message ---
--- Begin Message ---Subject: Re: bug#16129: 24.3.50; Emacs slow with follow-mode when buffer ends before last window Date: Mon, 06 Jan 2014 18:33:02 +0200 > Date: Mon, 6 Jan 2014 09:20:03 +0100 > From: Anders Lindgren <address@hidden> > Cc: Stefan Monnier <address@hidden>, address@hidden > > I think the incorrect state occurs when the new early exit occurs from > redsplay_window. When I added the condition "&& PT == w->last_point", both > the recentering problem and speed issues were solved. Indeed, this was my conclusion as well. (Except that PT is not quite right, as the window could be displaying a buffer that is not the current one at that early point in redisplay_window.) What this caused was that the window redisplay was mistakenly skipped, but then we marked that window's display "accurate", which confused the heck out of the display engine. So I installed the patch below to fix this regression, and I'm marking this bug done. Feel free to reopen if there are any leftovers. Btw, I strongly recommend against messing with window-start (or anything else that potentially requires redisplay) in a post-command-hook: doing so disables some important redisplay optimizations, and can easily trigger subtle misfeatures. I suggest to look for a better method to do what follow-mode needs to do, even if that means we'd have to implement a special hook we don't yet have. Thanks. === modified file 'src/xdisp.c' --- src/xdisp.c 2014-01-01 17:44:48 +0000 +++ src/xdisp.c 2014-01-06 16:21:39 +0000 @@ -15621,7 +15621,8 @@ redisplay_window (Lisp_Object window, bo && REDISPLAY_SOME_P () && !w->redisplay && !f->redisplay - && !buffer->text->redisplay) + && !buffer->text->redisplay + && BUF_PT (buffer) == w->last_point) return; /* Make sure that both W's markers are valid. */
--- End Message ---
[Prev in Thread] | Current Thread | [Next in Thread] |