[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unfreezing the display during auto-repeated scrolling. Simpler appro

From: Alan Mackenzie
Subject: Re: Unfreezing the display during auto-repeated scrolling. Simpler approach.
Date: Wed, 29 Oct 2014 14:52:11 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hello, Eli.

On Wed, Oct 29, 2014 at 04:14:12PM +0200, Eli Zaretskii wrote:
> > From: Stefan Monnier <address@hidden>
> > Date: Tue, 28 Oct 2014 20:57:16 -0400
> > Cc: Eli Zaretskii <address@hidden>, address@hidden

> > I'm beginning to like your C-level hack.

> And I still dislike it.

Just to be absolutely clear, we're talking about my _simpler_ hack, the
one that binds fontification-functions to nil during scrolling.  The
previous complicated one, that messed with "struct it"s, I think we can
all agree is dead.

What that proposed change does is simple and very restricted.  It binds
fontification-functions to nil ONLY in the two scrolling function (up
and down), ONLY when scrolling is being done by screenfulls rather than
by lines, and ONLY when the user option (precise mechanism not yet
worked out) use-default-face-for-fast-scrolling is non-nil.

By suggesting the use of jit-lock-defer, somehow, to speed up scrolling,
the principle that scrolled over buffer regions MUST be fontified has
been given up.

My attempts to get jit-lock-defer to do the Right Thing yesterday
weren't encouraging.

I'm guessing you still accept that the problem (frozen screen during and
after auto-repeated scrolling) needs to be solved.

An approach I haven't tried yet would be to use the existing scrolling
functionality for discreet key presses, changing to
nilled-out-fontification-functions when the keystrokes are coming in at
auto-repeat rates.  This might need enhancement of the command loop, or
keyboard interrupt handler, or whatever.

What do you think?

Alan Mackenzie (Nuremberg, Germany).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]