* C-n is very slow in Font-Lock mode @ 2005-04-23 16:16 Richard Stallman 2005-04-23 20:17 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: Richard Stallman @ 2005-04-23 16:16 UTC (permalink / raw) With Font-Lock mode enabled, starting from the beginning of a large file (such as fileio.c), C-n with a large argument (I tried C-u 2536 C-n) took many seconds. I think it was fontifying all the text that it moved across. Can this be avoided? I don't think C-n ought to need to fontify all that text. Even once it has fontified, the command still takes a lot longer with Font-Lock mode enabled than it does with Font-Lock disabled. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-23 16:16 C-n is very slow in Font-Lock mode Richard Stallman @ 2005-04-23 20:17 ` Eli Zaretskii 2005-04-24 21:23 ` Richard Stallman 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2005-04-23 20:17 UTC (permalink / raw) Cc: emacs-devel > From: Richard Stallman <rms@gnu.org> > Date: Sat, 23 Apr 2005 12:16:35 -0400 > > With Font-Lock mode enabled, starting from the beginning of a large > file (such as fileio.c), C-n with a large argument (I tried C-u 2536 > C-n) took many seconds. I think it was fontifying all the text > that it moved across. Probably. JIT lock fontifies any portion of a buffer that is becoming visible, and C-n makes visible all parts of the buffer it moves across, one page at a time. > Can this be avoided? I don't think C-n ought to need to fontify > all that text. Try setting jit-lock-defer-time to a non-nil value. Anyway, C-n is a very inefficient method of paging through a buffer. If you want to move 2536 lines, you will be better off using goto-line or C-v. JIT lock is optimized for C-v and similar methods that page by large chunks of text rather than by one line. > Even once it has fontified, the command still takes a lot longer > with Font-Lock mode enabled than it does with Font-Lock disabled. I'm guessing this is because the display engine looks up all the text properties put on the text by font-lock. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-23 20:17 ` Eli Zaretskii @ 2005-04-24 21:23 ` Richard Stallman 2005-04-24 21:50 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: Richard Stallman @ 2005-04-24 21:23 UTC (permalink / raw) Cc: emacs-devel JIT lock is optimized for C-v and similar methods that page by large chunks of text rather than by one line. I am not sure what that means, in concrete terms of Lisp program actions. I'm also not sure what you mean by "make text visible". It turns out that vertical-motion was fontifying all the text that it moved over. That seems to be easy to fix. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-24 21:23 ` Richard Stallman @ 2005-04-24 21:50 ` Eli Zaretskii 2005-04-26 10:05 ` Richard Stallman 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2005-04-24 21:50 UTC (permalink / raw) Cc: emacs-devel > From: Richard Stallman <rms@gnu.org> > CC: emacs-devel@gnu.org > Date: Sun, 24 Apr 2005 17:23:07 -0400 > > It turns out that vertical-motion was fontifying all the text that > it moved over. That seems to be easy to fix. Did you try my suggestion of customizing jit-lock-defer-time? I think this is the way of getting what you want; no need to fix anything. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-24 21:50 ` Eli Zaretskii @ 2005-04-26 10:05 ` Richard Stallman 2005-04-26 10:27 ` David Kastrup 2005-04-26 18:05 ` Eli Zaretskii 0 siblings, 2 replies; 26+ messages in thread From: Richard Stallman @ 2005-04-26 10:05 UTC (permalink / raw) Cc: emacs-devel > It turns out that vertical-motion was fontifying all the text that > it moved over. That seems to be easy to fix. Did you try my suggestion of customizing jit-lock-defer-time? No, because I want to fix this, not work around it. vertical-motion is a cursor motion function. It should not fontify anything. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-26 10:05 ` Richard Stallman @ 2005-04-26 10:27 ` David Kastrup 2005-04-26 22:56 ` Richard Stallman 2005-04-26 18:05 ` Eli Zaretskii 1 sibling, 1 reply; 26+ messages in thread From: David Kastrup @ 2005-04-26 10:27 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel Richard Stallman <rms@gnu.org> writes: > > It turns out that vertical-motion was fontifying all the text that > > it moved over. That seems to be easy to fix. > > Did you try my suggestion of customizing jit-lock-defer-time? > > No, because I want to fix this, not work around it. vertical-motion > is a cursor motion function. It should not fontify anything. vertical-motion is a built-in function in `C source code'. (vertical-motion LINES &optional WINDOW) Move point to start of the screen line LINES lines down. If LINES is negative, this means moving up. This function is an ordinary cursor motion function which calculates the new position based on how text would be displayed. The new position may be the start of a line, or just the start of a continuation line. [...] I don't see how vertical-motion can be expected to calculate the new position based on how text would be displayed if it is not allowed to figure out how text would be displayed. So for its correct behavior, it is mandatory to do the font locking. The only exception to that would be if the user would have specified that it is ok to work with unfontified text. One way to do that is to set jit-lock-defer-time. I think it would be reasonable if jit-lock-defer-time (currently defaulting to nil) would instead default to 0, with 0 meaning that font locking will occur without delay before displaying stuff, but not otherwise (maybe that setting already does that, but I have not checked). This would mean that paging back and forth over previously nonfontified stuff would not necessarily lead to the same position, but that still no surprisingly unfontified stuff would show up on the display. But with the current settings, it appears to me that vertical-motion can't reasonably do something different. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-26 10:27 ` David Kastrup @ 2005-04-26 22:56 ` Richard Stallman 2005-04-27 8:59 ` Kim F. Storm 2005-04-27 9:06 ` Eli Zaretskii 0 siblings, 2 replies; 26+ messages in thread From: Richard Stallman @ 2005-04-26 22:56 UTC (permalink / raw) Cc: eliz, emacs-devel So for its correct behavior, it is mandatory to do the font locking. The only exception to that would be if the user would have specified that it is ok to work with unfontified text. You are right. I will change it back. One way to do that is to set jit-lock-defer-time. Are you suggesting this as a change in the defaults? I'm not interested in this as a workaround for me alone; I want to make it faster for everyone. I found a way to change line-move-1 not to use vertical-motion in simple cases. I think it should work, but I don't understand the reason why the code uses vertical-motion. Can anyone add a comment to explain why? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-26 22:56 ` Richard Stallman @ 2005-04-27 8:59 ` Kim F. Storm 2005-04-27 9:57 ` Eli Zaretskii 2005-04-27 9:06 ` Eli Zaretskii 1 sibling, 1 reply; 26+ messages in thread From: Kim F. Storm @ 2005-04-27 8:59 UTC (permalink / raw) Cc: eliz, emacs-devel Richard Stallman <rms@gnu.org> writes: > I found a way to change line-move-1 not to use vertical-motion > in simple cases. I think it should work, but I don't understand > the reason why the code uses vertical-motion. > > Can anyone add a comment to explain why? The code has used vertical-motion since CVS revision 1.1 (Dec. 1991), and I don't see anything relevant in the older ChangeLogs, so who knows? -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-27 8:59 ` Kim F. Storm @ 2005-04-27 9:57 ` Eli Zaretskii 2005-04-27 12:27 ` Kim F. Storm 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2005-04-27 9:57 UTC (permalink / raw) Cc: emacs-devel > From: storm@cua.dk (Kim F. Storm) > Date: Wed, 27 Apr 2005 10:59:39 +0200 > Cc: eliz@gnu.org, emacs-devel@gnu.org > > The code has used vertical-motion since CVS revision 1.1 (Dec. 1991), > and I don't see anything relevant in the older ChangeLogs, so who knows? "cvs annotate" tells more; see my other message in this thread. I found that ChangeLog entry using annotate's information. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-27 9:57 ` Eli Zaretskii @ 2005-04-27 12:27 ` Kim F. Storm 0 siblings, 0 replies; 26+ messages in thread From: Kim F. Storm @ 2005-04-27 12:27 UTC (permalink / raw) Cc: emacs-devel "Eli Zaretskii" <eliz@gnu.org> writes: >> From: storm@cua.dk (Kim F. Storm) >> Date: Wed, 27 Apr 2005 10:59:39 +0200 >> Cc: eliz@gnu.org, emacs-devel@gnu.org >> >> The code has used vertical-motion since CVS revision 1.1 (Dec. 1991), >> and I don't see anything relevant in the older ChangeLogs, so who knows? > > "cvs annotate" tells more; see my other message in this thread. I > found that ChangeLog entry using annotate's information. So did I :-) I ended up with line-move from simple.el rev 1.1: (defun line-move (arg) (if (not (or (eq last-command 'next-line) (eq last-command 'previous-line))) (setq temporary-goal-column (if (and track-eol (eolp) ;; Don't count beg of empty line as end of line ;; unless we just did explicit end-of-line. (or (not (bolp)) (eq last-command 'end-of-line))) 9999 (current-column)))) (if (not (integerp selective-display)) (forward-line arg) ;; Move by arg lines, but ignore invisible ones. (while (> arg 0) (vertical-motion 1) (forward-char -1) (forward-line 1) (setq arg (1- arg))) (while (< arg 0) (vertical-motion -1) (beginning-of-line) (setq arg (1+ arg)))) (move-to-column (or goal-column temporary-goal-column)) nil) This shows that line-move has always(?) used vertical-motion as the basic method to skip invisible text. Richard's change that you refer to: 1995-03-09 Richard Stallman <rms@pogo.gnu.ai.mit.edu> * simple.el (line-move-ignore-invisible): New variable. (line-move): If that var is set, use vertical-motion. Skip any extra invis chars beyond where vertical-motion stops. just introduced line-move-ignore-invisible to control whether (the existing) vertical-motion is called at all. A later change to line-move introduced the explicit checking for invisible text using line-move-invisible-p. 2001-12-28 Richard M. Stallman <rms@gnu.org> * simple.el (line-move-invisible): New subroutine. (line-move-to-column): New subroutine--smarter about advancing over invisible parts of a line, or lines, but only as long as hpos grows. (line-move-finish): New subroutine: repeatedly processes desired column, intangibility, and fields. (line-move): Use those subroutines. When moving lines downward, skip invisible text first rather than last. Perhaps as a result of that change, vertical-motion is no longer needed in line-move, as it is(?) only called when there is no invisible text "around" point. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-26 22:56 ` Richard Stallman 2005-04-27 8:59 ` Kim F. Storm @ 2005-04-27 9:06 ` Eli Zaretskii 2005-04-28 11:00 ` Richard Stallman 1 sibling, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2005-04-27 9:06 UTC (permalink / raw) Cc: emacs-devel > From: Richard Stallman <rms@gnu.org> > CC: eliz@gnu.org, emacs-devel@gnu.org > Date: Tue, 26 Apr 2005 18:56:25 -0400 > > One way to do that is to set jit-lock-defer-time. > > Are you suggesting this as a change in the defaults? > I'm not interested in this as a workaround for me alone; > I want to make it faster for everyone. It could be the default (a value such as 0.2 would be good, I think), although I'm not sure how users will react: the current behavior in 21.x series of Emacs is effectively as if jit-lock-defer-time were nil, and I don't think I've seen a significant number of complaints about scrolling. Personally, I'd reset that option to nil if its default were changed, because I rarely page through a buffer with C-n, and because on modern machines the slowdown is barely visible, but the flash of unfontified text is annoyingly obvious. But that's just me. > I found a way to change line-move-1 not to use vertical-motion > in simple cases. I think it should work, but I don't understand > the reason why the code uses vertical-motion. It's ancient history, from before the display engine was rewritten for Emacs 21. Here's the relevant entry from the logs: 1995-03-09 Richard Stallman <rms@pogo.gnu.ai.mit.edu> * simple.el (line-move-ignore-invisible): New variable. (line-move): If that var is set, use vertical-motion. Skip any extra invis chars beyond where vertical-motion stops. So it seems like you ought to know the reason ;-) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-27 9:06 ` Eli Zaretskii @ 2005-04-28 11:00 ` Richard Stallman 0 siblings, 0 replies; 26+ messages in thread From: Richard Stallman @ 2005-04-28 11:00 UTC (permalink / raw) Cc: emacs-devel 1995-03-09 Richard Stallman <rms@pogo.gnu.ai.mit.edu> * simple.el (line-move-ignore-invisible): New variable. (line-move): If that var is set, use vertical-motion. Skip any extra invis chars beyond where vertical-motion stops. So it seems like you ought to know the reason ;-) I wish I remembered. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-26 10:05 ` Richard Stallman 2005-04-26 10:27 ` David Kastrup @ 2005-04-26 18:05 ` Eli Zaretskii 2005-04-26 21:38 ` David Kastrup 1 sibling, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2005-04-26 18:05 UTC (permalink / raw) Cc: emacs-devel > From: Richard Stallman <rms@gnu.org> > CC: emacs-devel@gnu.org > Date: Tue, 26 Apr 2005 06:05:41 -0400 > > > It turns out that vertical-motion was fontifying all the text that > > it moved over. That seems to be easy to fix. > > Did you try my suggestion of customizing jit-lock-defer-time? > > No, because I want to fix this, not work around it. vertical-motion > is a cursor motion function. It should not fontify anything. As David pointed out, vertical-motion does that for a good reason: fontification can well change the pixel size of the glyphs that Emacs needs to display. I think jit-lock-defer-time _is_ the way to avoid the slowness if you are willing to see the text unfontified for a fraction of a second. IIRC, Stefan introduced that option to provide functionality similar to now-obsolete lazy-lock. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-26 18:05 ` Eli Zaretskii @ 2005-04-26 21:38 ` David Kastrup 2005-04-26 22:43 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: David Kastrup @ 2005-04-26 21:38 UTC (permalink / raw) Cc: rms, emacs-devel "Eli Zaretskii" <eliz@gnu.org> writes: >> From: Richard Stallman <rms@gnu.org> >> CC: emacs-devel@gnu.org >> Date: Tue, 26 Apr 2005 06:05:41 -0400 >> >> > It turns out that vertical-motion was fontifying all the text that >> > it moved over. That seems to be easy to fix. >> >> Did you try my suggestion of customizing jit-lock-defer-time? >> >> No, because I want to fix this, not work around it. vertical-motion >> is a cursor motion function. It should not fontify anything. > > As David pointed out, vertical-motion does that for a good reason: > fontification can well change the pixel size of the glyphs that Emacs > needs to display. > > I think jit-lock-defer-time _is_ the way to avoid the slowness if > you are willing to see the text unfontified for a fraction of a > second. I think that a separate value of 0 where is one not willing to see text unfontified, but willing to have motion calculated with a still unfontified text, would make perfect sense. It might be that jit-lock-defer-time already happens to work this way. If not, it probably should, and 0 instead of nil should be the default value. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-26 21:38 ` David Kastrup @ 2005-04-26 22:43 ` Eli Zaretskii 2005-04-26 22:57 ` David Kastrup 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2005-04-26 22:43 UTC (permalink / raw) Cc: emacs-devel > Cc: rms@gnu.org, emacs-devel@gnu.org > From: David Kastrup <dak@gnu.org> > Date: Tue, 26 Apr 2005 23:38:11 +0200 > > > I think jit-lock-defer-time _is_ the way to avoid the slowness if > > you are willing to see the text unfontified for a fraction of a > > second. > > I think that a separate value of 0 where is one not willing to see > text unfontified, but willing to have motion calculated with a still > unfontified text, would make perfect sense. jit-lock-defer-time works by setting up an idle timer. Will run-with-idle-timer work if you give it a zero time-out? And fontification of the visible portion will take time during which one still sees unfontified text, anyway. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-26 22:43 ` Eli Zaretskii @ 2005-04-26 22:57 ` David Kastrup 2005-04-27 9:19 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: David Kastrup @ 2005-04-26 22:57 UTC (permalink / raw) Cc: emacs-devel "Eli Zaretskii" <eliz@gnu.org> writes: >> Cc: rms@gnu.org, emacs-devel@gnu.org >> From: David Kastrup <dak@gnu.org> >> Date: Tue, 26 Apr 2005 23:38:11 +0200 >> >> > I think jit-lock-defer-time _is_ the way to avoid the slowness if >> > you are willing to see the text unfontified for a fraction of a >> > second. >> >> I think that a separate value of 0 where is one not willing to see >> text unfontified, but willing to have motion calculated with a >> still unfontified text, would make perfect sense. > > jit-lock-defer-time works by setting up an idle timer. Will > run-with-idle-timer work if you give it a zero time-out? Without looking at the code, it would be my guess that it would currently run immediately after redisplay, whereas my suggestion for jit-lock-defer-time=0 semantics would be that it be run immediately before redisplay. > And fontification of the visible portion will take time during which > one still sees unfontified text, anyway. Not if it happens before redisplay. As I said, I think this would make perfect sense for this setting. If we want to differentiate for some reason between immediately before and immediately after redisplay, it would also be possible to use a negative value for "just before redisplay" and 0 for "just after redisplay". It would possibly make sense to implement this distinction in the context of run-with-idle-timer, and then let jit-lock-defer-time just use it by defaulting to -1. Again: I have not looked at the code. It just appears to me that this would seem sensible behavior, and it would be nice to have an option to tell jit-lock not to bother fontifying stuff unless it is actually going to display it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-26 22:57 ` David Kastrup @ 2005-04-27 9:19 ` Eli Zaretskii 2005-04-27 9:43 ` David Kastrup 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2005-04-27 9:19 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: David Kastrup <dak@gnu.org> > Date: Wed, 27 Apr 2005 00:57:05 +0200 > > Without looking at the code, it would be my guess that it would > currently run immediately after redisplay, whereas my suggestion for > jit-lock-defer-time=0 semantics would be that it be run immediately > before redisplay. I'm not sure what that means. You _are_ aware that, when you scroll thru text with C-n or C-v, there's almost nothing going on in Emacs _except_ redisplay, yes? That is, all C-n does is move point one line; the rest is redisplay's job, including fontification. (The single most important new aspect of JIT lock as opposed to the old lazy-lock and its ilk was that JIT lock uses special hooks of the display engine, whereas the old, pre-v21 redisplay didn't have such hooks, and so lazy-lock needed to jump through the hoops to hook into every possible method of changing the displayed text.) So when you are saying ``before redisplay'', what exactly do you mean? Redisplay begins by computing the ``desired glyph matrix'', which is an internal representation of what should be on the screen; surely, before this happens, there's no way we could fontify the right portion of the text, since we have no idea what that portion is. > > And fontification of the visible portion will take time during which > > one still sees unfontified text, anyway. > > Not if it happens before redisplay. [...] > > It would possibly make sense to implement this distinction in the > context of run-with-idle-timer, and then let jit-lock-defer-time just > use it by defaulting to -1. Idle timers run when Emacs is idle, which by definition is _after_ redisplay did its job. So I think you are talking about some nw mechanism, which has nothing to do with how jit-lock-defer-time works now. > Again: I have not looked at the code. Well, perhaps you should. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-27 9:19 ` Eli Zaretskii @ 2005-04-27 9:43 ` David Kastrup 2005-04-27 10:17 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: David Kastrup @ 2005-04-27 9:43 UTC (permalink / raw) Cc: emacs-devel "Eli Zaretskii" <eliz@gnu.org> writes: >> Cc: emacs-devel@gnu.org >> From: David Kastrup <dak@gnu.org> >> Date: Wed, 27 Apr 2005 00:57:05 +0200 >> >> Without looking at the code, it would be my guess that it would >> currently run immediately after redisplay, whereas my suggestion for >> jit-lock-defer-time=0 semantics would be that it be run immediately >> before redisplay. > > I'm not sure what that means. You _are_ aware that, when you scroll > thru text with C-n or C-v, there's almost nothing going on in Emacs > _except_ redisplay, yes? We are talking about the situation where the input is coming in faster than Emacs can process it. In that case it will refrain from updating the display. The question is whether it should also refrain from fontification. Currently it doesn't. My proposal was to provide a special setting for jit-lock-defer-time that would not bother with fontification unless it was going to update the display. That would mean that vertical-motion could possibly work on unfontified stuff when Emacs was not keeping up with the display. > So when you are saying ``before redisplay'', what exactly do you > mean? Before material actually gets transferred to the screen. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-27 9:43 ` David Kastrup @ 2005-04-27 10:17 ` Eli Zaretskii 2005-04-27 11:32 ` David Kastrup 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2005-04-27 10:17 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: David Kastrup <dak@gnu.org> > Date: Wed, 27 Apr 2005 11:43:01 +0200 > > We are talking about the situation where the input is coming in faster > than Emacs can process it. See, we don't really know that. Whether this is true or not, depends on several unknown factors, like the rate of keyboard auto-repeat on the user's machine vs the time it takes Emacs on that machine, with that CPU and display type/toolkit to perform redisplay. In my experience, movement with C-n gives Emacs enough time to update the display. > In that case it will refrain from updating the display. The > question is whether it should also refrain from fontification. > > Currently it doesn't. Are you sure? Fontification is a side effect of redisplay, so if redisplay is not entered, I think there will be no fontification. > > So when you are saying ``before redisplay'', what exactly do you > > mean? > > Before material actually gets transferred to the screen. That's way _after_ almost all expensive portions of redisplay were done. Getting material to the screen, especially when motion was with C-n, is very fast; most of the time it takes to update the display is spent calculating what should be on the screen and finding the optimal way of updating it. So having such an option will not help alleviate the problem that started this thread: how to make C-n fast as if font-lock were not in effect. jit-lock-defer-time non-nil works by disabling fontification altogether until Emacs is idle. If fontification is not disabled, you yourself explained that vertical-motion _must_ fontify to keep its calculations accurate. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-27 10:17 ` Eli Zaretskii @ 2005-04-27 11:32 ` David Kastrup 2005-04-27 11:59 ` Eli Zaretskii 2005-04-28 11:00 ` Richard Stallman 0 siblings, 2 replies; 26+ messages in thread From: David Kastrup @ 2005-04-27 11:32 UTC (permalink / raw) Cc: emacs-devel "Eli Zaretskii" <eliz@gnu.org> writes: >> Cc: emacs-devel@gnu.org >> From: David Kastrup <dak@gnu.org> >> Date: Wed, 27 Apr 2005 11:43:01 +0200 >> >> We are talking about the situation where the input is coming in faster >> than Emacs can process it. > > See, we don't really know that. Whether this is true or not, > depends on several unknown factors, like the rate of keyboard > auto-repeat on the user's machine vs the time it takes Emacs on that > machine, with that CPU and display type/toolkit to perform > redisplay. > > In my experience, movement with C-n gives Emacs enough time to > update the display. The last time I looked, this thread was about Emacs not being fast enough to update the display. > jit-lock-defer-time non-nil works by disabling fontification > altogether until Emacs is idle. If fontification is not disabled, > you yourself explained that vertical-motion _must_ fontify to keep > its calculations accurate. It seems I am a complete failure at conveying my meaning. I was arguing for a setting where vertical-motion is allowed to keep its calculations inaccurate with regard to font locking. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-27 11:32 ` David Kastrup @ 2005-04-27 11:59 ` Eli Zaretskii 2005-04-27 12:23 ` David Kastrup 2005-04-27 12:32 ` Kim F. Storm 2005-04-28 11:00 ` Richard Stallman 1 sibling, 2 replies; 26+ messages in thread From: Eli Zaretskii @ 2005-04-27 11:59 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: David Kastrup <dak@gnu.org> > Date: Wed, 27 Apr 2005 13:32:11 +0200 > > >> We are talking about the situation where the input is coming in faster > >> than Emacs can process it. > > > > See, we don't really know that. Whether this is true or not, > > depends on several unknown factors, like the rate of keyboard > > auto-repeat on the user's machine vs the time it takes Emacs on that > > machine, with that CPU and display type/toolkit to perform > > redisplay. > > > > In my experience, movement with C-n gives Emacs enough time to > > update the display. > > The last time I looked, this thread was about Emacs not being fast > enough to update the display. Maybe it was, I just am not sure. Richard said "C-n is very slow" and gave an example of invoking C-n with a large numeric argument. The example would cause only one redisplay: at the end of movement, regardless of the rate input is coming in. That is not the only situation that jit-lock-defer-time was introduced to deal with, see below. > > jit-lock-defer-time non-nil works by disabling fontification > > altogether until Emacs is idle. If fontification is not disabled, > > you yourself explained that vertical-motion _must_ fontify to keep > > its calculations accurate. > > It seems I am a complete failure at conveying my meaning. Or I am a complete failure at understanding it. > I was arguing for a setting where vertical-motion is allowed to keep > its calculations inaccurate with regard to font locking. And I was trying to say that AFAIK currently there's no reliable way of deferring fontifications until just before the screen is redrawn. What you suggest will perhaps work in the single example given by Richard (and even then it requires some changes in the C code), but I see difficulty applying it to other situations. For example, consider the case where I press and hold C-v (a not-so-uncommon way of paging quickly through a large buffer): with your suggestion, unless Emacs never redraws a screen until I lift my fingers (a rare case with a reasonably fast machine and reasonably sized windows), the paging would be as slow as with jit-lock-defer-time set to nil, while setting it to something like 0.2 would make paging as fast as without font lock. In other words, the fact that Emacs becomes idle is a clear sign that the screen was updated and the displayed text must now be fontified. In your suggestion, what would be such a clear sign? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-27 11:59 ` Eli Zaretskii @ 2005-04-27 12:23 ` David Kastrup 2005-04-27 12:32 ` Kim F. Storm 1 sibling, 0 replies; 26+ messages in thread From: David Kastrup @ 2005-04-27 12:23 UTC (permalink / raw) Cc: emacs-devel "Eli Zaretskii" <eliz@gnu.org> writes: > Maybe it was, I just am not sure. Richard said "C-n is very slow" > and gave an example of invoking C-n with a large numeric argument. > The example would cause only one redisplay: at the end of movement, > regardless of the rate input is coming in. > That is not the only situation that jit-lock-defer-time was > introduced to deal with, see below. Sure. Making it do something sensible for one more application does not seem like a bad idea. >> > jit-lock-defer-time non-nil works by disabling fontification >> > altogether until Emacs is idle. If fontification is not >> > disabled, you yourself explained that vertical-motion _must_ >> > fontify to keep its calculations accurate. >> >> It seems I am a complete failure at conveying my meaning. > > Or I am a complete failure at understanding it. > >> I was arguing for a setting where vertical-motion is allowed to >> keep its calculations inaccurate with regard to font locking. > > And I was trying to say that AFAIK currently there's no reliable way > of deferring fontifications until just before the screen is redrawn. Well, I am afraid that I was completely unable to get that point from what you have written. I already said that I was not familiar with the code, but described a _behavior_ that I would consider useful. Now instead of arguing in various and, to my mind contradictory ways, about the usefulness of the behavior, it would have been easier to just say "Emacs can't do this at the current point of time, for this and that reason". Then one can think about whether the required effort would be worth investing or not. There is unfortunately some relevancy with regard to the release: there was quite a bit of agreement that it would be a generally desirable thing if Emacs had global fontlocking on by default, and one of the preconditions was that it would not cause serious regressions in usability/performance. So we need to figure out whether we can make do with changed settings and minor changes, and if not, whether the overall cost of enabling font locking by default can be considered tolerable nevertheless. > What you suggest will perhaps work in the single example given by > Richard (and even then it requires some changes in the C code), but > I see difficulty applying it to other situations. For example, > consider the case where I press and hold C-v (a not-so-uncommon way > of paging quickly through a large buffer): Yes. > with your suggestion, unless Emacs never redraws a screen until I > lift my fingers (a rare case with a reasonably fast machine and > reasonably sized windows), the paging would be as slow as with > jit-lock-defer-time set to nil, I don't really think so, since while it is redrawing and font locking a screenful of material, additional keypresses keep pouring in and will be processed in one batch before the next redraw is attempted. So the paging should get more jumpy, but the progress should not noticeably slow. Things are different with input devices that block autorepeat as long as the input is not being processed/queued. In that case, indeed the paging will be as slow as possible. > In other words, the fact that Emacs becomes idle is a clear sign > that the screen was updated and the displayed text must now be > fontified. In your suggestion, what would be such a clear sign? If Emacs is idle and there is nothing in the keyboard input queue waiting to be processed. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-27 11:59 ` Eli Zaretskii 2005-04-27 12:23 ` David Kastrup @ 2005-04-27 12:32 ` Kim F. Storm 2005-04-28 11:00 ` Richard Stallman 1 sibling, 1 reply; 26+ messages in thread From: Kim F. Storm @ 2005-04-27 12:32 UTC (permalink / raw) Cc: emacs-devel > And I was trying to say that AFAIK currently there's no reliable way > of deferring fontifications until just before the screen is redrawn. > What you suggest will perhaps work in the single example given by > Richard (and even then it requires some changes in the C code), Maybe this would work ? (if (input-pending-p) (forward-line 1) (vertical-motion 1)) -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-27 12:32 ` Kim F. Storm @ 2005-04-28 11:00 ` Richard Stallman 2005-04-28 12:16 ` David Kastrup 0 siblings, 1 reply; 26+ messages in thread From: Richard Stallman @ 2005-04-28 11:00 UTC (permalink / raw) Cc: eliz, emacs-devel Maybe this would work ? (if (input-pending-p) (forward-line 1) (vertical-motion 1)) It is incorrect for a cursor motion function to depend on whether input is pending. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-28 11:00 ` Richard Stallman @ 2005-04-28 12:16 ` David Kastrup 0 siblings, 0 replies; 26+ messages in thread From: David Kastrup @ 2005-04-28 12:16 UTC (permalink / raw) Cc: eliz, emacs-devel, Kim F. Storm Richard Stallman <rms@gnu.org> writes: > Maybe this would work ? > > (if (input-pending-p) > (forward-line 1) > (vertical-motion 1)) > > It is incorrect for a cursor motion function to depend on whether > input is pending. Agreed. I think it would be reasonable to allow some setting where the cursor motion happened without mandatory fontification in some rare circumstances when the display is delayed, but to generally flip the behavior around depending on that sounds overdone. It should be restricted to the performance critical case of fontification, it should be optional, and should rarely have an effect unless unexpectedly large unfontified areas amount point are involved. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: C-n is very slow in Font-Lock mode 2005-04-27 11:32 ` David Kastrup 2005-04-27 11:59 ` Eli Zaretskii @ 2005-04-28 11:00 ` Richard Stallman 1 sibling, 0 replies; 26+ messages in thread From: Richard Stallman @ 2005-04-28 11:00 UTC (permalink / raw) Cc: eliz, emacs-devel The last time I looked, this thread was about Emacs not being fast enough to update the display. It was about typing C-u 2500 C-n. Anyway, I think I have more or less fixed the problem with my last change to line-move-1. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2005-04-28 12:16 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-04-23 16:16 C-n is very slow in Font-Lock mode Richard Stallman 2005-04-23 20:17 ` Eli Zaretskii 2005-04-24 21:23 ` Richard Stallman 2005-04-24 21:50 ` Eli Zaretskii 2005-04-26 10:05 ` Richard Stallman 2005-04-26 10:27 ` David Kastrup 2005-04-26 22:56 ` Richard Stallman 2005-04-27 8:59 ` Kim F. Storm 2005-04-27 9:57 ` Eli Zaretskii 2005-04-27 12:27 ` Kim F. Storm 2005-04-27 9:06 ` Eli Zaretskii 2005-04-28 11:00 ` Richard Stallman 2005-04-26 18:05 ` Eli Zaretskii 2005-04-26 21:38 ` David Kastrup 2005-04-26 22:43 ` Eli Zaretskii 2005-04-26 22:57 ` David Kastrup 2005-04-27 9:19 ` Eli Zaretskii 2005-04-27 9:43 ` David Kastrup 2005-04-27 10:17 ` Eli Zaretskii 2005-04-27 11:32 ` David Kastrup 2005-04-27 11:59 ` Eli Zaretskii 2005-04-27 12:23 ` David Kastrup 2005-04-27 12:32 ` Kim F. Storm 2005-04-28 11:00 ` Richard Stallman 2005-04-28 12:16 ` David Kastrup 2005-04-28 11:00 ` Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.