"Eli Zaretskii" <[EMAIL PROTECTED]> 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 _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
