unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Eli Zaretskii" <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: C-n is very slow in Font-Lock mode
Date: Wed, 27 Apr 2005 14:59:52 +0300	[thread overview]
Message-ID: <01c54b20$Blat.v2.4$c54e3200@zahav.net.il> (raw)
In-Reply-To: <85d5sge9qc.fsf@lola.goethe.zz> (message from David Kastrup on Wed, 27 Apr 2005 13:32:11 +0200)

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

  reply	other threads:[~2005-04-27 11:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='01c54b20$Blat.v2.4$c54e3200@zahav.net.il' \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).