C-n is very slow in Font-Lock mode

C-n is very slow in Font-Lock mode

[Richard Stallman]

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.

Re: C-n is very slow in Font-Lock mode

[Eli Zaretskii]

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

Re: C-n is very slow in Font-Lock mode

[Richard Stallman]

      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.

Re: C-n is very slow in Font-Lock mode

[Eli Zaretskii]

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

Re: C-n is very slow in Font-Lock mode

[Richard Stallman]

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

Re: C-n is very slow in Font-Lock mode

[David Kastrup]

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

Re: C-n is very slow in Font-Lock mode

[Eli Zaretskii]

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

Re: C-n is very slow in Font-Lock mode

[David Kastrup]

"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

Re: C-n is very slow in Font-Lock mode

[Eli Zaretskii]

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

Re: C-n is very slow in Font-Lock mode

[Richard Stallman]

    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?

Re: C-n is very slow in Font-Lock mode

[David Kastrup]

"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

Re: C-n is very slow in Font-Lock mode

[Kim F. Storm]

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

Re: C-n is very slow in Font-Lock mode

[Eli Zaretskii]

> 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 ;-)

Re: C-n is very slow in Font-Lock mode

[Eli Zaretskii]

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

Re: C-n is very slow in Font-Lock mode

[David Kastrup]

"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

Re: C-n is very slow in Font-Lock mode

[Eli Zaretskii]

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

Re: C-n is very slow in Font-Lock mode

[Eli Zaretskii]

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

Re: C-n is very slow in Font-Lock mode

[David Kastrup]

"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

Re: C-n is very slow in Font-Lock mode

[Eli Zaretskii]

> 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?

Re: C-n is very slow in Font-Lock mode

[David Kastrup]

"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

Re: C-n is very slow in Font-Lock mode

[Kim F. Storm]

"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

Re: C-n is very slow in Font-Lock mode

[Kim F. Storm]

> 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

Re: C-n is very slow in Font-Lock mode

[Richard Stallman]

      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.

Re: C-n is very slow in Font-Lock mode

[Richard Stallman]

    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.

Re: C-n is very slow in Font-Lock mode

[Richard Stallman]

    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.

Re: C-n is very slow in Font-Lock mode

[David Kastrup]

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