* follow-mode: extremely slow in combination with org-mode
@ 2018-06-16 10:25 Gerald Wildgruber
2018-06-16 11:41 ` Eli Zaretskii
2018-06-21 8:25 ` Anders Lindgren
0 siblings, 2 replies; 18+ messages in thread
From: Gerald Wildgruber @ 2018-06-16 10:25 UTC (permalink / raw)
To: emacs-devel
Hi,
I have got a problem with enormous lag while entering text in buffers
with emacs follow-mode enabled.
I'm using emacs (git checkout v. 27.0.50) and Org mode (git checkout
release_9.1.13-760-g8def68).
My work is solely text-based, using org-mode. A typical setup is to use
a maximized or full screen emacs frame split into five windows
positioned vertically one next to the other on a 40" 4k display. All
five windows display one and the same file, that is opened using emacs
follow-mode, so that every window is displaying a portion of the same
file in a continuous manner (simultaneously displaying up to 45kb of
text in one frame, an entire paper).
Unfortunately, with this setup there is terrible lag with every single
key input (on a very fast quad core machine); every key stroke produces
a 100% processor load.
If I deactivate follow-mode, the problem disappears. It also gets better
if I enable text-mode instead of org-mode.
I then used the elisp profiler (M-x profiler-start/report) to find out
which function uses most cpu time while editing text in said setup. Here
is the result:
Collapsed, the report looks like that:
+ command-execute 8789 47%
+ follow-post-command-hook 7755 41%
+ ... 1976 10%
+ redisplay_internal (C function) 104 0%
+ yas--post-command-handler 40 0%
+ timer-event-handler 20 0%
tooltip-hide 7 0%
And somewhat expanded:
- follow-post-command-hook 7755 41%
- follow-adjust-window 7755 41%
- follow-windows-start-end 7732 41%
- follow-calc-win-end 7732 41%
+ pos-visible-in-window-p 25 0%
+ posn-at-x-y 7 0%
+ window-inside-pixel-edges 3 0%
+ follow-all-followers 4 0%
follow-avoid-tail-recenter 3 0%
If I understand correctly "follow-calc-win-end" would be the function
that uses most of cpu time.
I then did additional profiling with the elp library, adding relevant
functions under "Command-execute" and "follow-post-command-hook" to
elp-function-list, edited text, and then did M-x elp-results. It showed
again that "follow-calc-win-end" by far used most of cpu time.
Anyone got an idea what's going on here and how to debug that? Are there
possible optimizations with this situation? Or is this "normal",
expected behavior, simply due to the number of windows and text
displayed?
Thanks
Gerald.
---------------------
Sent with mu4e
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: follow-mode: extremely slow in combination with org-mode 2018-06-16 10:25 follow-mode: extremely slow in combination with org-mode Gerald Wildgruber @ 2018-06-16 11:41 ` Eli Zaretskii 2018-06-16 13:06 ` Gerald Wildgruber 2018-06-21 8:25 ` Anders Lindgren 1 sibling, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2018-06-16 11:41 UTC (permalink / raw) To: Gerald Wildgruber; +Cc: emacs-devel > From: Gerald Wildgruber <wildgruber@tu-berlin.de> > Date: Sat, 16 Jun 2018 12:25:13 +0200 > > - follow-post-command-hook 7755 41% > - follow-adjust-window 7755 41% > - follow-windows-start-end 7732 41% > - follow-calc-win-end 7732 41% > + pos-visible-in-window-p 25 0% > + posn-at-x-y 7 0% > + window-inside-pixel-edges 3 0% > + follow-all-followers 4 0% > follow-avoid-tail-recenter 3 0% > > If I understand correctly "follow-calc-win-end" would be the function > that uses most of cpu time. Yes, it looks like that. For even more detailed results, repeat the experiment after loading the uncompiled follow.el. > Anyone got an idea what's going on here and how to debug that? Are there > possible optimizations with this situation? Or is this "normal", > expected behavior, simply due to the number of windows and text > displayed? If you "show all" in the Org buffer, do the lags become significantly smaller? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-16 11:41 ` Eli Zaretskii @ 2018-06-16 13:06 ` Gerald Wildgruber 2018-06-16 16:25 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Gerald Wildgruber @ 2018-06-16 13:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Sa, Jun 16 2018, Eli Zaretskii <eliz@gnu.org> wrote: >> If I understand correctly "follow-calc-win-end" would be the function >> that uses most of cpu time. > > Yes, it looks like that. For even more detailed results, repeat the > experiment after loading the uncompiled follow.el. Thanks Eli, So what I did was: 1. M-x load-file RET path-to-follow.el.gz RET 2. M-x profiler start 3. edit text 4. M-x profiler-report Results do indeed look slightly different: - follow-post-command-hook 140786 88% - if 140440 88% - let 140440 88% - save-current-buffer 140440 88% - follow-adjust-window 140436 88% - if 140436 88% - progn 140436 88% - let 140418 88% - let* 140340 88% - if 140327 87% - follow-redisplay 114860 72% - let* 114860 72% - cond 104536 65% - follow-calculate-first-window-start-from-above 104536 65% - save-excursion 104536 65% - let 104536 65% - while 104536 65% - if 104536 65% - setq 103381 64% - follow-calc-win-start 103381 64% - while 103381 64% - let 103378 64% - setq 103349 64% - car 103349 64% - follow-calc-win-end 103346 64% - apply 103346 64% - #<compiled 0x226e139> 103329 64% - apply 103322 64% - #<lambda 0xe5f44dcc127a05e> 103313 64% - let* 103310 64% posn-point 51699 32% + if 51546 32% + window-inside-pixel-edges 47 0% + 3 0% set-window-start 4 0% + and 3 0% + not 1155 0% + let 4361 2% + follow-calc-win-start 3289 2% + follow-estimate-first-window-start 2674 1% - setq 20770 13% - follow-windows-start-end 20770 13% - if 20770 13% - let 20770 13% - let 20770 13% - while 20770 13% - setq 20770 13% - cons 20770 13% - cons 20770 13% - cons 20770 13% - follow-calc-win-end 20767 13% - apply 20767 13% + #<compiled 0x226e139> 20763 13% + let 4635 2% + if 62 0% + progn 13 0% + if 67 0% + follow-all-followers 11 0% + follow-avoid-tail-recenter 18 0% + if 4 0% + follow-adjust-window 346 0% + command-execute 9690 6% > If you "show all" in the Org buffer, do the lags become significantly > smaller? Yes, the difference is VERY significant; but I guess this is because with collapsed headings, there is A LOT more text within the boundaries of my frame, than with show-all. Gerald. --------------------- Sent with mu4e ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-16 13:06 ` Gerald Wildgruber @ 2018-06-16 16:25 ` Eli Zaretskii 2018-06-16 21:05 ` Gerald Wildgruber 2018-06-17 6:57 ` Gerald Wildgruber 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2018-06-16 16:25 UTC (permalink / raw) To: Gerald Wildgruber; +Cc: emacs-devel > From: Gerald Wildgruber <wildgruber@tu-berlin.de> > CC: <emacs-devel@gnu.org> > Date: Sat, 16 Jun 2018 15:06:49 +0200 > > > - follow-calc-win-start 103381 64% > - while 103381 64% > - let 103378 64% > - setq 103349 64% > - car 103349 64% > - follow-calc-win-end 103346 64% > - apply 103346 64% > - #<compiled 0x226e139> 103329 64% > - apply 103322 64% > - #<lambda 0xe5f44dcc127a05e> 103313 64% > - let* 103310 64% > posn-point 51699 32% > + if 51546 32% > + window-inside-pixel-edges 47 0% There's something here I don't understand. This profile says that follow-calc-win-end calls posn-point via two 'apply' calls, a byte-compiled function, and a lambda-function. But there's nothing like that in follow.el that I could see. Did you advise some functions in follow.el? If not, what are those intermediate calls? > > If you "show all" in the Org buffer, do the lags become significantly > > smaller? > > Yes, the difference is VERY significant; but I guess this is because > with collapsed headings, there is A LOT more text within the boundaries > of my frame, than with show-all. How much is "A LOT more"? How many physical lines do you have in typical single window in that Org buffer? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-16 16:25 ` Eli Zaretskii @ 2018-06-16 21:05 ` Gerald Wildgruber 2018-06-17 6:57 ` Gerald Wildgruber 1 sibling, 0 replies; 18+ messages in thread From: Gerald Wildgruber @ 2018-06-16 21:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Sa, Jun 16 2018, Eli Zaretskii <eliz@gnu.org> wrote: > There's something here I don't understand. This profile says that > follow-calc-win-end calls posn-point via two 'apply' calls, a > byte-compiled function, and a lambda-function. But there's nothing > like that in follow.el that I could see. Did you advise some > functions in follow.el? If not, what are those intermediate calls? No definitely not: I didn't modify any of the functions. But I will repeat the profiling to see, if I get the same results or If I made an error. Gerald. --------------------- Sent with mu4e ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-16 16:25 ` Eli Zaretskii 2018-06-16 21:05 ` Gerald Wildgruber @ 2018-06-17 6:57 ` Gerald Wildgruber 2018-06-17 8:12 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: Gerald Wildgruber @ 2018-06-17 6:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Sa, Jun 16 2018, Eli Zaretskii <eliz@gnu.org> wrote: > There's something here I don't understand. This profile says that > follow-calc-win-end calls posn-point via two 'apply' calls, a > byte-compiled function, and a lambda-function. But there's nothing > like that in follow.el that I could see. Did you advise some > functions in follow.el? If not, what are those intermediate calls? I repeated the profiling two times; the intermediate calls disappeared; I can't say what might have caused them; here is the result: - follow-post-command-hook 21938 71% - if 21938 71% - let 21938 71% - save-current-buffer 21938 71% - follow-adjust-window 21933 71% - if 21933 71% - progn 21933 71% - let 21906 71% - let* 21906 71% - progn 17609 57% - follow-windows-start-end 17606 57% - if 17606 57% - let 17603 57% - let 17603 57% - while 17603 57% - setq 17599 57% - cons 17599 57% - cons 17599 57% - cons 17599 57% - follow-calc-win-end 17591 57% - let* 17591 57% - if 9229 30% + let 1115 3% + pos-visible-in-window-p 26 0% posn-point 8350 27% + window-inside-pixel-edges 12 0% + follow-cache-valid-p 3 0% + follow-update-window-start 3 0% - if 4297 13% - follow-redisplay 3329 10% - let* 3329 10% - cond 2924 9% - follow-calculate-first-window-start-from-above 2924 9% - save-excursion 2924 9% - let 2924 9% - while 2924 9% - if 2924 9% - setq 2899 9% - follow-calc-win-start 2899 9% - while 2899 9% - let 2899 9% - setq 2896 9% - car 2896 9% - follow-calc-win-end 2896 9% - let* 2896 9% posn-point 1455 4% if 1441 4% set-window-start 3 0% + not 25 0% + let 169 0% + follow-calc-win-start 125 0% + follow-estimate-first-window-start 111 0% + let 598 1% + setq 364 1% + follow-avoid-tail-recenter 3 0% + and 3 0% + follow-avoid-tail-recenter 27 0% set-buffer 5 0% >> > If you "show all" in the Org buffer, do the lags become significantly >> > smaller? >> >> Yes, the difference is VERY significant; but I guess this is because >> with collapsed headings, there is A LOT more text within the boundaries >> of my frame, than with show-all. > > How much is "A LOT more"? How many physical lines do you have in > typical single window in that Org buffer? When I do a SHOW-ALL, my emacs frame split into those five windows connected by follow-mode show about 700 lines of (natural language) text. If COLLAPSED, it can be up to several thousand lines of text hidden under the org headings (typically two to ten thousand lines). Gerald. --------------------- Sent with mu4e ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-17 6:57 ` Gerald Wildgruber @ 2018-06-17 8:12 ` Eli Zaretskii 2018-06-17 11:13 ` Alan Mackenzie 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2018-06-17 8:12 UTC (permalink / raw) To: Gerald Wildgruber, Alan Mackenzie; +Cc: emacs-devel > From: Gerald Wildgruber <wildgruber@tu-berlin.de> > CC: <emacs-devel@gnu.org> > Date: Sun, 17 Jun 2018 08:57:22 +0200 > > - follow-windows-start-end 17606 57% > - if 17606 57% > - let 17603 57% > - let 17603 57% > - while 17603 57% > - setq 17599 57% > - cons 17599 57% > - cons 17599 57% > - cons 17599 57% > - follow-calc-win-end 17591 57% > - let* 17591 57% > - if 9229 30% > + let 1115 3% > + pos-visible-in-window-p 26 0% > posn-point 8350 27% > + window-inside-pixel-edges 12 0% Alan, why doesn't follow-calc-win-end doesn't just use window-end with last argument non-nil? AFAU, that should allow you to compute the result using 1/4 of the processing time you now invest. Why do you need all the rest in that function? What am I missing? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-17 8:12 ` Eli Zaretskii @ 2018-06-17 11:13 ` Alan Mackenzie 2018-06-17 13:02 ` Eli Zaretskii 2018-06-17 15:13 ` Eli Zaretskii 0 siblings, 2 replies; 18+ messages in thread From: Alan Mackenzie @ 2018-06-17 11:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Gerald Wildgruber, emacs-devel Hello, Eli. On Sun, Jun 17, 2018 at 11:12:39 +0300, Eli Zaretskii wrote: > > From: Gerald Wildgruber <wildgruber@tu-berlin.de> > > CC: <emacs-devel@gnu.org> > > Date: Sun, 17 Jun 2018 08:57:22 +0200 > > - follow-windows-start-end 17606 57% > > - if 17606 57% > > - let 17603 57% > > - let 17603 57% > > - while 17603 57% > > - setq 17599 57% > > - cons 17599 57% > > - cons 17599 57% > > - cons 17599 57% > > - follow-calc-win-end 17591 57% > > - let* 17591 57% > > - if 9229 30% > > + let 1115 3% > > + pos-visible-in-window-p 26 0% > > posn-point 8350 27% > > + window-inside-pixel-edges 12 0% > Alan, why doesn't follow-calc-win-end doesn't just use window-end with > last argument non-nil? AFAU, that should allow you to compute the > result using 1/4 of the processing time you now invest. Why do you > need all the rest in that function? What am I missing? I honestly don't know for sure. But on 2014-04-27 I made a note in my personal log: "In follow-calc-win-end, we check for EOB being visible in the window, rather than being the window-end. There needs to be a comment here about what the last element means." . I wish I could decipher what I meant, then. I think I might have encountered a corner case, where EOB is _inside_ a window, possibly not even the last window, and using window-end failed for some reason. But I think follow-calc-win-end was in the original follow.el written by Anders Lindgren. Maybe, back in the mists of time, window-end didn't work for some reason - maybe it hadn't yet acquired it's UPDATE argument, or something like that. follow-calc-win-end was much longer in Emacs-21.4, and carried the comment "This function is optimized function for speed!". It had got shorter some time up to Emacs-24.5, where it had already started using posn-point. This rewrite was probably this: commit c93b886f957b55df4fe45d986c34242832ec4a28 Author: Chong Yidong <cyd@gnu.org> Date: Sun Apr 29 09:48:23 2012 +0800 Fix Follow mode's calculation of window ends. * lisp/follow.el (follow-calc-win-end): Rewrite to handle partial screen lines correctly. (follow-avoid-tail-recenter): Minor cleanup. Fixes: debbugs:8390 Why we don't just use window-end, I don't know. Maybe the sequence of people who've modified follow-calc-win-end have all assumed their predecessors understood why a simple window-end wasn't used. If it is something to do with EOB messing things up, maybe we could amend window-end better to handle EOB. Sorry I can't do any more than speculate, here. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-17 11:13 ` Alan Mackenzie @ 2018-06-17 13:02 ` Eli Zaretskii 2018-06-17 14:56 ` Gerald Wildgruber 2018-06-17 15:13 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2018-06-17 13:02 UTC (permalink / raw) To: Alan Mackenzie; +Cc: wildgruber, emacs-devel > Date: Sun, 17 Jun 2018 11:13:33 +0000 > Cc: Gerald Wildgruber <wildgruber@tu-berlin.de>, emacs-devel@gnu.org > From: Alan Mackenzie <acm@muc.de> > > On Sun, Jun 17, 2018 at 11:12:39 +0300, Eli Zaretskii wrote: > > > From: Gerald Wildgruber <wildgruber@tu-berlin.de> > > > CC: <emacs-devel@gnu.org> > > > Date: Sun, 17 Jun 2018 08:57:22 +0200 > > > > - follow-windows-start-end 17606 57% > > > - if 17606 57% > > > - let 17603 57% > > > - let 17603 57% > > > - while 17603 57% > > > - setq 17599 57% > > > - cons 17599 57% > > > - cons 17599 57% > > > - cons 17599 57% > > > - follow-calc-win-end 17591 57% > > > - let* 17591 57% > > > - if 9229 30% > > > + let 1115 3% > > > + pos-visible-in-window-p 26 0% > > > posn-point 8350 27% > > > + window-inside-pixel-edges 12 0% > > > Alan, why doesn't follow-calc-win-end doesn't just use window-end with > > last argument non-nil? AFAU, that should allow you to compute the > > result using 1/4 of the processing time you now invest. Why do you > > need all the rest in that function? What am I missing? > > I honestly don't know for sure. But on 2014-04-27 I made a note in my > personal log: > > "In follow-calc-win-end, we check for EOB being visible in the > window, rather than being the window-end. There needs to be a > comment here about what the last element means." > > . I wish I could decipher what I meant, then. I think I might have > encountered a corner case, where EOB is _inside_ a window, possibly not > even the last window, and using window-end failed for some reason. > > But I think follow-calc-win-end was in the original follow.el written by > Anders Lindgren. Maybe, back in the mists of time, window-end didn't > work for some reason - maybe it hadn't yet acquired it's UPDATE > argument, or something like that. OK, thanks for the explanations. Gerald, could you try the following patch to follow-calc-win-end? Please first see if this makes it significantly faster in your use cases, and if so, please run with it for a while and see if there are some adverse effects. (If this is not faster, it isn't worth testing it more.) diff --git a/lisp/follow.el b/lisp/follow.el index fd397c0..c99fc93 100644 --- a/lisp/follow.el +++ b/lisp/follow.el @@ -925,14 +925,17 @@ follow-calc-win-end the last fully-visible line in WIN. END-OF-BUFFER is t when EOB is fully-visible in WIN. If WIN is nil, the selected window is used." - (let* ((win (or win (selected-window))) - (edges (window-inside-pixel-edges win)) - (ht (- (nth 3 edges) (nth 1 edges))) - (last-line-pos (posn-point (posn-at-x-y 0 (1- ht) win)))) - (if (pos-visible-in-window-p last-line-pos win) - (let ((end (window-end win t))) - (list end (pos-visible-in-window-p (point-max) win))) - (list last-line-pos nil)))) + (or win (setq win (selected-window))) + (with-selected-window win + (let* ((wend (window-end win t)) + (endp (= wend (point-max)))) + (and (> wend (point-min)) + (setq wend (1- wend))) + (setq wend + (save-excursion + (goto-char wend) + (line-beginning-position))) + (list wend endp)))) (defun follow-calc-win-start (windows pos win) "Determine the start of window WIN in a Follow mode window chain. ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-17 13:02 ` Eli Zaretskii @ 2018-06-17 14:56 ` Gerald Wildgruber 2018-06-17 15:10 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Gerald Wildgruber @ 2018-06-17 14:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Mackenzie, emacs-devel Thanks again Eli and Alan for picking this up! Eli: the patch didn't apply cleanly (with "patch -p1 <" or "git apply"), but as it is so simple I applied it manually. follow-calc-win-end now looks like that: ================================================== (defun follow-calc-win-end (&optional win) "Calculate the end position for window WIN. Return (END-POS END-OF-BUFFER). Actually, the position returned is the start of the line after the last fully-visible line in WIN. END-OF-BUFFER is t when EOB is fully-visible in WIN. If WIN is nil, the selected window is used." (or win (setq win (selected-window))) (with-selected-window win (let* ((wend (window-end win t)) (endp (= wend (point-max)))) (and (> wend (point-min)) (setq wend (1- wend))) (setq wend (save-excursion (goto-char wend) (line-beginning-position))) (list wend endp)))) ================================================== I byte compiled the patched follow.el restarted emacs and began editing. It actually seems somewhat faster, though not enormously; I will continue working with this patched version to see how it goes; I have a more problematic (=slower) machine in my office, and I'm am eager to see, if it makes a difference there; at home, where I'm testing right now, its a new quad core xeon with 64gb of ram, -- and it is kind of strange that with such a machine fans start very audibly as soon as you start TYPING (not video editing or the like) :-) One more observation: it might be that the slowing down becomes more noticeable, the closer point gets to the bottom of the last window (lower right edge of my five-fold splitted emacs frame), but I couldn't reproduce this consistently. Please count on me for any other testing that might be necessary! I'm no programmer but will do my best to deliver usable results. Here's how the profile looks now, with the patched, uncompiled follow.el loaded right before profiling: - follow-post-command-hook 17642 40% - if 17642 40% - let 17642 40% - save-current-buffer 17642 40% - follow-adjust-window 17642 40% - if 17642 40% - progn 17642 40% - let 17591 40% - let* 17560 40% - progn 16733 38% - follow-windows-start-end 16730 38% - if 16730 38% - let 16730 38% - let 16730 38% - while 16730 38% - setq 16719 38% - cons 16564 37% - cons 16560 37% - cons 16560 37% - follow-calc-win-end 16557 37% - let 16557 37% - save-current-buffer 16557 37% - unwind-protect 16557 37% - progn 16551 37% let* 16548 37% internal--after-with-selected-window 3 0% + follow-windows-start-end 155 0% + if 827 1% + follow-all-followers 27 0% + follow-avoid-tail-recenter 51 0% + command-execute 17015 38% Gerald. On So, Jun 17 2018, Eli Zaretskii <eliz@gnu.org> wrote: > Gerald, could you try the following patch to follow-calc-win-end? > Please first see if this makes it significantly faster in your use > cases, and if so, please run with it for a while and see if there are > some adverse effects. (If this is not faster, it isn't worth testing > it more.) > > diff --git a/lisp/follow.el b/lisp/follow.el > index fd397c0..c99fc93 100644 > --- a/lisp/follow.el > +++ b/lisp/follow.el > @@ -925,14 +925,17 @@ follow-calc-win-end > the last fully-visible line in WIN. END-OF-BUFFER is t when EOB > is fully-visible in WIN. If WIN is nil, the selected window is > used." > - (let* ((win (or win (selected-window))) > - (edges (window-inside-pixel-edges win)) > - (ht (- (nth 3 edges) (nth 1 edges))) > - (last-line-pos (posn-point (posn-at-x-y 0 (1- ht) win)))) > - (if (pos-visible-in-window-p last-line-pos win) > - (let ((end (window-end win t))) > - (list end (pos-visible-in-window-p (point-max) win))) > - (list last-line-pos nil)))) > + (or win (setq win (selected-window))) > + (with-selected-window win > + (let* ((wend (window-end win t)) > + (endp (= wend (point-max)))) > + (and (> wend (point-min)) > + (setq wend (1- wend))) > + (setq wend > + (save-excursion > + (goto-char wend) > + (line-beginning-position))) > + (list wend endp)))) > > (defun follow-calc-win-start (windows pos win) > "Determine the start of window WIN in a Follow mode window chain. --------------------- Sent with mu4e ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-17 14:56 ` Gerald Wildgruber @ 2018-06-17 15:10 ` Eli Zaretskii 2018-06-19 12:08 ` Gerald Wildgruber 2018-06-19 13:53 ` Gerald Wildgruber 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2018-06-17 15:10 UTC (permalink / raw) To: Gerald Wildgruber; +Cc: acm, emacs-devel > From: Gerald Wildgruber <wildgruber@tu-berlin.de> > CC: Alan Mackenzie <acm@muc.de>, <emacs-devel@gnu.org> > Date: Sun, 17 Jun 2018 16:56:00 +0200 > > I byte compiled the patched follow.el restarted emacs and began editing. > > It actually seems somewhat faster, though not enormously; If the speedup is not significant, then I guess there are other factors at work, although the profile seemed to show I was eliminating the hottest function calls. > I will continue working with this patched version to see how it > goes; I have a more problematic (=slower) machine in my office, and > I'm am eager to see, if it makes a difference there; at home, where > I'm testing right now, its a new quad core xeon with 64gb of ram, -- > and it is kind of strange that with such a machine fans start very > audibly as soon as you start TYPING (not video editing or the like) > :-) Each character you insert triggers redisplay, and I'm guessing follow-mode has many of the redisplay optimizations disabled. But it may be interesting to see a profile when all you do is type self-inserting characters, maybe we will learn something important from that. > One more observation: it might be that the slowing down becomes more > noticeable, the closer point gets to the bottom of the last window > (lower right edge of my five-fold splitted emacs frame), but I couldn't > reproduce this consistently. This could be due to follow-calc-win-start, which loops over windows. Or maybe there's another loop. Again, a profile might tell something interesting. > Please count on me for any other testing that might be necessary! I'm no > programmer but will do my best to deliver usable results. > > Here's how the profile looks now, with the patched, uncompiled follow.el > loaded right before profiling: Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-17 15:10 ` Eli Zaretskii @ 2018-06-19 12:08 ` Gerald Wildgruber 2018-06-19 16:55 ` Eli Zaretskii 2018-06-19 13:53 ` Gerald Wildgruber 1 sibling, 1 reply; 18+ messages in thread From: Gerald Wildgruber @ 2018-06-19 12:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: acm, emacs-devel Hi I tried the patched follow.el (the one that contains the modified follow-calc-win-end) on my somewhat slower (but also new quad core) office machine, unfortunately no amelioration of lag was noticeable. Same procedure: patching follow.el, starting the profiler, loading the patched uncompiled version into emacs via M-x load-file and finally start editing. The lag remains enormous (e.g. more than a second lag between typing RET and seeing a newline on screen); I noticed however, that upon typing RET one time, the newline comes almost immediately; but after typing more RETs they take ages to appear on screen. Bizarrely, this happened also: redisplay takes very long and it apparently aborts leaving paragraphs before point unfilled, one long line of text (I always use auto-fill-mode). On So, Jun 17 2018, Eli Zaretskii <eliz@gnu.org> wrote: > Each character you insert triggers redisplay, and I'm guessing > follow-mode has many of the redisplay optimizations disabled. Actually, I had no idea. I tried to understand what "redisplay" is (by reading the comments at the beginning of emacs/src/xdisp.c) and the more I read, the less I am surprised it takes so long! :-) Why might those optimizations have been disabled on follow-mode? > But it may be interesting to see a profile when all you do is type > self-inserting characters, maybe we will learn something important > from that. Here is another profile, now on my office machine with only self-inserting commands, i.e. typing just "normal" letters: - follow-post-command-hook 54982 61% - if 54982 61% - let 54975 61% - save-current-buffer 54975 61% - follow-adjust-window 54975 61% - if 54972 61% - progn 54972 61% - let 53646 59% - let* 53646 59% - if 53646 59% - follow-redisplay 49062 54% - let* 49062 54% - cond 43568 48% - follow-calculate-first-window-start-from-above 43568 48% - save-excursion 43568 48% - let 43568 48% - while 43564 48% - if 43564 48% - setq 42813 47% - follow-calc-win-start 42813 47% - while 42813 47% - let 42802 47% - setq 42789 47% - car 42789 47% - follow-calc-win-end 42785 47% - let 42785 47% - save-current-buffer 42785 47% - unwind-protect 42785 47% - progn 42777 47% - let* 42767 47% + setq 10 0% + window-end 4 0% + and 7 0% + not 747 0% if 4 0% + follow-calc-win-start 3062 3% + follow-estimate-first-window-start 1410 1% + let 1022 1% - let 4574 5% - redisplay 4570 5% - redisplay_internal (C function) 17 0% - eval 11 0% if 8 0% mode-line-eol-desc 3 0% + follow-avoid-tail-recenter 7 0% if 3 0% + follow-windows-start-end 1326 1% + progn 3 0% + follow-post-command-hook 3 0% + command-execute 27012 30% Anything else to try to get a faster follow-mode? Thanks Gerald. --------------------- Sent with mu4e ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-19 12:08 ` Gerald Wildgruber @ 2018-06-19 16:55 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2018-06-19 16:55 UTC (permalink / raw) To: Gerald Wildgruber; +Cc: acm, emacs-devel > From: Gerald Wildgruber <wildgruber@tu-berlin.de> > CC: <acm@muc.de>, <emacs-devel@gnu.org> > Date: Tue, 19 Jun 2018 14:08:44 +0200 > > I tried the patched follow.el (the one that contains the modified > follow-calc-win-end) on my somewhat slower (but also new quad core) > office machine, unfortunately no amelioration of lag was noticeable. > > Same procedure: patching follow.el, starting the profiler, loading the > patched uncompiled version into emacs via M-x load-file and finally > start editing. > > The lag remains enormous (e.g. more than a second lag between typing RET > and seeing a newline on screen); I noticed however, that upon typing RET > one time, the newline comes almost immediately; but after typing more > RETs they take ages to appear on screen. > > Bizarrely, this happened also: redisplay takes very long and it > apparently aborts leaving paragraphs before point unfilled, one long > line of text (I always use auto-fill-mode). Then this method of debugging the problem is no longer efficient, I'd need to run this on my system to see what's going on. So please use "M-x report-emacs-bug RET" to file a bug report about this, and please attach to the report the Org file where you observe the problems. (You can replace the text of the headings and the bodies of your entries with some random character, to protect your private stuff, but please leave the parts that control Org mode intact.) Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-17 15:10 ` Eli Zaretskii 2018-06-19 12:08 ` Gerald Wildgruber @ 2018-06-19 13:53 ` Gerald Wildgruber 1 sibling, 0 replies; 18+ messages in thread From: Gerald Wildgruber @ 2018-06-19 13:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: acm, emacs-devel Hi I tried the patched follow.el (the one that contains the modified follow-calc-win-end) on my somewhat slower (but also new quad core) office machine, unfortunately no amelioration of lag was noticeable. Same procedure: patching follow.el, starting the profiler, loading the patched uncompiled version into emacs via M-x load-file and finally start editing. The lag remains enormous (e.g. more than a second lag between typing RET and seeing a newline on screen); I noticed however, that upon typing RET one time, the newline comes almost immediately; but after typing more RETs they take ages to appear on screen. Bizarrely, this happened also: redisplay takes very long and it apparently aborts leaving paragraphs before point unfilled, one long line of text (I always use auto-fill-mode). On So, Jun 17 2018, Eli Zaretskii <eliz@gnu.org> wrote: > Each character you insert triggers redisplay, and I'm guessing > follow-mode has many of the redisplay optimizations disabled. Actually, I had no idea. I tried to understand what "redisplay" is (by reading the comments at the beginning of emacs/src/xdisp.c) and the more I read, the less I am surprised it takes so long! :-) Why might those optimizations have been disabled on follow-mode? > But it may be interesting to see a profile when all you do is type > self-inserting characters, maybe we will learn something important > from that. Here is another profile, now on my office machine with only self-inserting commands, i.e. typing just "normal" letters: - follow-post-command-hook 54982 61% - if 54982 61% - let 54975 61% - save-current-buffer 54975 61% - follow-adjust-window 54975 61% - if 54972 61% - progn 54972 61% - let 53646 59% - let* 53646 59% - if 53646 59% - follow-redisplay 49062 54% - let* 49062 54% - cond 43568 48% - follow-calculate-first-window-start-from-above 43568 48% - save-excursion 43568 48% - let 43568 48% - while 43564 48% - if 43564 48% - setq 42813 47% - follow-calc-win-start 42813 47% - while 42813 47% - let 42802 47% - setq 42789 47% - car 42789 47% - follow-calc-win-end 42785 47% - let 42785 47% - save-current-buffer 42785 47% - unwind-protect 42785 47% - progn 42777 47% - let* 42767 47% + setq 10 0% + window-end 4 0% + and 7 0% + not 747 0% if 4 0% + follow-calc-win-start 3062 3% + follow-estimate-first-window-start 1410 1% + let 1022 1% - let 4574 5% - redisplay 4570 5% - redisplay_internal (C function) 17 0% - eval 11 0% if 8 0% mode-line-eol-desc 3 0% + follow-avoid-tail-recenter 7 0% if 3 0% + follow-windows-start-end 1326 1% + progn 3 0% + follow-post-command-hook 3 0% + command-execute 27012 30% Anything else to try to get a faster follow-mode? Thanks Gerald. --------------------- Sent with mu4e ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-17 11:13 ` Alan Mackenzie 2018-06-17 13:02 ` Eli Zaretskii @ 2018-06-17 15:13 ` Eli Zaretskii 1 sibling, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2018-06-17 15:13 UTC (permalink / raw) To: Alan Mackenzie; +Cc: wildgruber, emacs-devel > Date: Sun, 17 Jun 2018 11:13:33 +0000 > From: Alan Mackenzie <acm@muc.de> > Cc: Gerald Wildgruber <wildgruber@tu-berlin.de>, emacs-devel@gnu.org > > commit c93b886f957b55df4fe45d986c34242832ec4a28 > Author: Chong Yidong <cyd@gnu.org> > Date: Sun Apr 29 09:48:23 2012 +0800 > > Fix Follow mode's calculation of window ends. > > * lisp/follow.el (follow-calc-win-end): Rewrite to handle partial > screen lines correctly. > (follow-avoid-tail-recenter): Minor cleanup. > > Fixes: debbugs:8390 Btw, bug#8390 is back. My testing indicates that it was fixed in Emacs 24.3 (I guess by the above change), and then became broken again in Emacs 24.4. Try "C-x C--" in a buffer under follow-mode, and you will see the erratic behavior. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-16 10:25 follow-mode: extremely slow in combination with org-mode Gerald Wildgruber 2018-06-16 11:41 ` Eli Zaretskii @ 2018-06-21 8:25 ` Anders Lindgren 2018-06-27 16:43 ` Gerald Wildgruber 1 sibling, 1 reply; 18+ messages in thread From: Anders Lindgren @ 2018-06-21 8:25 UTC (permalink / raw) To: Gerald Wildgruber; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 5178 bytes --] Hi! There can be a number of reasons why follow-mode is slow. The main problem is that is it's time consuming to recompute the window state, and even more time consuming when aligning the windows. For simple commands like point movement, follow-mode assumes that the content of the buffers hasn't changed and retain the existing layout, whereas for other commands (including self-insert-command), everything is recomputed and realigned. However, I use six side by side windows, and a small font, giving me a total of almost 800 consecutive lines, and it typically runs fine without any noticeable lag. There are a number of factors that can have a negative impact on follow-mode: - It run slower on a 32 bit binary than on a 64 bit binary (at least under Windows). (For this reason, I used Emacs 22 at work for many years, until prebuilt 64 bit binaries of modern Emacs versions were available.) - Follow-mode is has problems when the width of the windows differ, especially if you have long lines that spill over from one window to another. I've written a support package to set up side-by-side windows in a pixel-perfect way, https://github.com/Lindydancer/multicolumn -- please try if and see if follow-mode runs more smoothly. One thing that I have had on my wish-list for a very long time (20+ years) is that normal typing should use and update the cache, to speed things up. Of course, this only work as long as the editing doesn't change the layout, like when inserting a newline or make a line so long that it wraps. Unfortunately, I don't think that I will have time for it anytime soon, but I'm happy to share my ideas if someone else is willing to make a try. What made me curious that you said that the slow-down only occurs with org-mode. My guess is that invisible text makes it harder for Emacs to calculate window layout properties. Sincerely, Anders Lindgren (I wrote follow-mode when I was a student, in the mid 1990:s) On Sat, Jun 16, 2018 at 12:25 PM, Gerald Wildgruber <wildgruber@tu-berlin.de > wrote: > > Hi, > > I have got a problem with enormous lag while entering text in buffers > with emacs follow-mode enabled. > > I'm using emacs (git checkout v. 27.0.50) and Org mode (git checkout > release_9.1.13-760-g8def68). > > My work is solely text-based, using org-mode. A typical setup is to use > a maximized or full screen emacs frame split into five windows > positioned vertically one next to the other on a 40" 4k display. All > five windows display one and the same file, that is opened using emacs > follow-mode, so that every window is displaying a portion of the same > file in a continuous manner (simultaneously displaying up to 45kb of > text in one frame, an entire paper). > > Unfortunately, with this setup there is terrible lag with every single > key input (on a very fast quad core machine); every key stroke produces > a 100% processor load. > > If I deactivate follow-mode, the problem disappears. It also gets better > if I enable text-mode instead of org-mode. > > I then used the elisp profiler (M-x profiler-start/report) to find out > which function uses most cpu time while editing text in said setup. Here > is the result: > > Collapsed, the report looks like that: > > + command-execute 8789 47% > + follow-post-command-hook 7755 41% > + ... 1976 10% > + redisplay_internal (C function) 104 0% > + yas--post-command-handler 40 0% > + timer-event-handler 20 0% > tooltip-hide 7 0% > > > And somewhat expanded: > > - follow-post-command-hook 7755 41% > - follow-adjust-window 7755 41% > - follow-windows-start-end 7732 41% > - follow-calc-win-end 7732 41% > + pos-visible-in-window-p 25 0% > + posn-at-x-y 7 0% > + window-inside-pixel-edges 3 0% > + follow-all-followers 4 0% > follow-avoid-tail-recenter 3 0% > > If I understand correctly "follow-calc-win-end" would be the function > that uses most of cpu time. > > I then did additional profiling with the elp library, adding relevant > functions under "Command-execute" and "follow-post-command-hook" to > elp-function-list, edited text, and then did M-x elp-results. It showed > again that "follow-calc-win-end" by far used most of cpu time. > > Anyone got an idea what's going on here and how to debug that? Are there > possible optimizations with this situation? Or is this "normal", > expected behavior, simply due to the number of windows and text > displayed? > > Thanks > > Gerald. > > --------------------- > Sent with mu4e > > [-- Attachment #2: Type: text/html, Size: 8166 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: follow-mode: extremely slow in combination with org-mode 2018-06-21 8:25 ` Anders Lindgren @ 2018-06-27 16:43 ` Gerald Wildgruber 2018-07-09 20:12 ` Anders Lindgren 0 siblings, 1 reply; 18+ messages in thread From: Gerald Wildgruber @ 2018-06-27 16:43 UTC (permalink / raw) To: Anders Lindgren; +Cc: emacs-devel Hi Anders thanks for your reply: I just returned to office and couldn't answer earlier! On Do, Jun 21 2018, Anders Lindgren <andlind@gmail.com> wrote: > Hi! > > There can be a number of reasons why follow-mode is slow. The main problem > is that is it's time consuming to recompute the window state, and even more > time consuming when aligning the windows. For simple commands like point > movement, follow-mode assumes that the content of the buffers hasn't > changed and retain the existing layout, whereas for other commands > (including self-insert-command), everything is recomputed and realigned. > > However, I use six side by side windows, and a small font, giving me a > total of almost 800 consecutive lines, and it typically runs fine without > any noticeable lag. That's quite close to my setup. However: when I use org-mode, with entire branches collapsed, there might well be several thousand (2000-15000) lines of text in the buffer; if all this is recalculated every time I enter a letter, -- perhaps the lags I observe are "normal". But then, the machine I'm working on is a really fast and new computer. > There are a number of factors that can have a negative impact on > follow-mode: > - It run slower on a 32 bit binary than on a 64 bit binary (at least under > Windows). (For this reason, I used Emacs 22 at work for many years, until > prebuilt 64 bit binaries of modern Emacs versions were available.) Mine are 64 bit machines. > - Follow-mode is has problems when the width of the windows differ, > especially if you have long lines that spill over from one window to > another. I've written a support package to set up side-by-side windows in a > pixel-perfect way, https://github.com/Lindydancer/multicolumn -- please try > if and see if follow-mode runs more smoothly. Actually I use this already! I have in my .emacs the following: (require 'multicolumn) (multicolumn-global-mode 1) > One thing that I have had on my wish-list for a very long time (20+ years) > is that normal typing should use and update the cache, to speed things up. > Of course, this only work as long as the editing doesn't change the layout, > like when inserting a newline or make a line so long that it wraps. > Unfortunately, I don't think that I will have time for it anytime soon, but > I'm happy to share my ideas if someone else is willing to make a try. I hope someone picks this up!!! :-) Can you tell if the function that uses so much of cpu time -- follow-calc-win-end -- in the form it is now part of new emacs versions, has any evident problem compared to your own longer version in pre version 22 emacs? Cf Alan's posting in this thread: https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00522.html > What made me curious that you said that the slow-down only occurs with > org-mode. My guess is that invisible text makes it harder for Emacs to > calculate window layout properties. Yes: the lag is much lower with text-mode. Thanks again Gerald. > Sincerely, > Anders Lindgren (I wrote follow-mode when I was a student, in the mid > 1990:s) > > > On Sat, Jun 16, 2018 at 12:25 PM, Gerald Wildgruber <wildgruber@tu-berlin.de >> wrote: > >> >> Hi, >> >> I have got a problem with enormous lag while entering text in buffers >> with emacs follow-mode enabled. >> >> I'm using emacs (git checkout v. 27.0.50) and Org mode (git checkout >> release_9.1.13-760-g8def68). >> >> My work is solely text-based, using org-mode. A typical setup is to use >> a maximized or full screen emacs frame split into five windows >> positioned vertically one next to the other on a 40" 4k display. All >> five windows display one and the same file, that is opened using emacs >> follow-mode, so that every window is displaying a portion of the same >> file in a continuous manner (simultaneously displaying up to 45kb of >> text in one frame, an entire paper). >> >> Unfortunately, with this setup there is terrible lag with every single >> key input (on a very fast quad core machine); every key stroke produces >> a 100% processor load. >> >> If I deactivate follow-mode, the problem disappears. It also gets better >> if I enable text-mode instead of org-mode. >> >> I then used the elisp profiler (M-x profiler-start/report) to find out >> which function uses most cpu time while editing text in said setup. Here >> is the result: >> >> Collapsed, the report looks like that: >> >> + command-execute 8789 47% >> + follow-post-command-hook 7755 41% >> + ... 1976 10% >> + redisplay_internal (C function) 104 0% >> + yas--post-command-handler 40 0% >> + timer-event-handler 20 0% >> tooltip-hide 7 0% >> >> >> And somewhat expanded: >> >> - follow-post-command-hook 7755 41% >> - follow-adjust-window 7755 41% >> - follow-windows-start-end 7732 41% >> - follow-calc-win-end 7732 41% >> + pos-visible-in-window-p 25 0% >> + posn-at-x-y 7 0% >> + window-inside-pixel-edges 3 0% >> + follow-all-followers 4 0% >> follow-avoid-tail-recenter 3 0% >> >> If I understand correctly "follow-calc-win-end" would be the function >> that uses most of cpu time. >> >> I then did additional profiling with the elp library, adding relevant >> functions under "Command-execute" and "follow-post-command-hook" to >> elp-function-list, edited text, and then did M-x elp-results. It showed >> again that "follow-calc-win-end" by far used most of cpu time. >> >> Anyone got an idea what's going on here and how to debug that? Are there >> possible optimizations with this situation? Or is this "normal", >> expected behavior, simply due to the number of windows and text >> displayed? >> >> Thanks >> >> Gerald. >> >> --------------------- >> Sent with mu4e >> >> -- Dr. Gerald Wildgruber Institut für Philosophie, Literatur-, Wissenschafts- und Technikgeschichte Literaturwissenschaft mit Schwerpunkt Literatur und Wissenschaft Technische Universität Berlin Straße des 17. Juni 135 D-10623 Berlin http://www.philosophie.tu-berlin.de/menue/home/ T. +49 (0)30 314 25924 F. +49 (0)30 314 23107 wildgruber@tu-berlin.de --------------------- Sent with mu4e ^ permalink raw reply [flat|nested] 18+ messages in thread
* follow-mode: extremely slow in combination with org-mode 2018-06-27 16:43 ` Gerald Wildgruber @ 2018-07-09 20:12 ` Anders Lindgren 0 siblings, 0 replies; 18+ messages in thread From: Anders Lindgren @ 2018-07-09 20:12 UTC (permalink / raw) To: Gerald Wildgruber; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 3621 bytes --] Hi! I decided to go to the bottom of this, and had to do some digging, which took a little bit longer than I thought it would do, sorry about the delay. On Wed, Jun 27, 2018 at 6:43 PM, Gerald Wildgruber <wildgruber@tu-berlin.de> wrote: > > - Follow-mode is has problems when the width of the windows differ, > > especially if you have long lines that spill over from one window to > > another. I've written a support package to set up side-by-side windows > in a > > pixel-perfect way, https://github.com/Lindydancer/multicolumn -- please > try > > if and see if follow-mode runs more smoothly. > > Actually I use this already! [...] > You just made my day! Can you tell if the function that uses so much of cpu time -- > follow-calc-win-end -- in the form it is now part of new emacs versions, > has any evident problem compared to your own longer version in pre > version 22 emacs? Cf Alan's posting in this thread: > https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00522.html > > The main difference is that the current version handles clipped lines at the end of a window. My original version predates the addition of the UPDATE optional parameter to window-end. Effectively, it calculated window-end plus one. Anyway, it would not work in a modern Emacs where fonts of different heights could be used. The modern version handles clipped lines by repeating a clipped screen line in the next window. This is for two reasons: 1) Lines where only one or a few pixels are displayed would effectively be hidden from users, if they weren't repeated in the next window. 2) When the cursor is placed on a clipped line, Emacs recenters the window, which breaks Follow mode. Instead, Follow mode selects the next window, which is displaying the same line. (Or rather, this is the way it was supposed to work, I just noticed that it is broken in Emacs 26.1 -- the original window is scrolled anyway. I don't know how long it as been broken.) Lines in this context are screen lines, not physical lines. In other words, if you have a long wrapped physical line, the function should return a suitable position inside the line where the next window should start. The follow-calc-win-end function should return window-end plus one if the line isn't clipped, and the beginning of the bottommost screen line if it is clipped. (The patch supplied by Eli doesn't do this, so it won't work -- but I guess its main purpose of the patch was to figure out which parts of the function consume processing power.) So, where do we go from here? First, I noticed that pos-visible-in-window-p can take an argument PARTIALLY that, when non-nil, makes the function provide information about whether or not the position is partially visible. Presumably, it could replace the pixel juggling the current function do. However, if the big time thief is `window-end` with an non-nil UPDATE argument we must either make is faster (at least after self-insert-command) or figure out a way to avoid calling it too often, somehow. Being (somewhat) older and ((hopefully) somewhat) wiser, I wish I had written a test suite for Follow mode, or at least a test protocol. However, Follow mode was written 12 years before work on Ert even had started... Anyway, having a test suite containing all the corner cases would make it easier to try out alternative implementations, and it would prevent us from introducing bugs like the one I just found. I wished I had more time to work on this, but it took me a week just to find the time to write this mail, so clearly I'm not the best candidate at the moment. Sincerely, Anders Lindgren [-- Attachment #2: Type: text/html, Size: 4915 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2018-07-09 20:12 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-06-16 10:25 follow-mode: extremely slow in combination with org-mode Gerald Wildgruber 2018-06-16 11:41 ` Eli Zaretskii 2018-06-16 13:06 ` Gerald Wildgruber 2018-06-16 16:25 ` Eli Zaretskii 2018-06-16 21:05 ` Gerald Wildgruber 2018-06-17 6:57 ` Gerald Wildgruber 2018-06-17 8:12 ` Eli Zaretskii 2018-06-17 11:13 ` Alan Mackenzie 2018-06-17 13:02 ` Eli Zaretskii 2018-06-17 14:56 ` Gerald Wildgruber 2018-06-17 15:10 ` Eli Zaretskii 2018-06-19 12:08 ` Gerald Wildgruber 2018-06-19 16:55 ` Eli Zaretskii 2018-06-19 13:53 ` Gerald Wildgruber 2018-06-17 15:13 ` Eli Zaretskii 2018-06-21 8:25 ` Anders Lindgren 2018-06-27 16:43 ` Gerald Wildgruber 2018-07-09 20:12 ` Anders Lindgren
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).