Re: Unfreezing the display during auto-repeated scrolling.

[Alan Mackenzie]

Hello, Eli.

A lot of your post has become overtaken by other things in the last few
hours, but I'll answer anyway.

On Mon, Oct 27, 2014 at 06:48:10PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 27 Oct 2014 10:05:26 +0000
> > Cc: address@hidden, address@hidden
> > From: Alan Mackenzie <address@hidden>

> > I care a great deal about accuracy here.  Perhaps we understand
> > different things by "accuracy".

> Perhaps.  Do you at least agree that when font-lock faces change the
> font, not just colors, your changes will cause scrolling to sometimes
> land on a line other than what would happen without your changes?
> That's what I meant by "accuracy".

Yes, I do.  However, I can't persuade myself that this is anything but a
special case.  Do people actually use mixtures of faces where the font
isn't the same as the default's?  What for?

> > > .... you could simply move in physical lines.  That's fast and doesn't
> > > need any support from the display engine.

> > This would end up in the wrong place if there were as much as a single
> > continued line in the window.

> The same will happen with your changes, in some situations.

Admitted.

> > When a user types a single PageDown/PageUp, it MUST scroll reliably
> > to the right place.

> So we can have a variant of scroll-up/down that behaves like today on
> the first invocation, and thereafter switches to moving point
> instead.  Would that do what you want?

No.  Typing a sequence of deliberate scroll-ups/downs, one at a time, is
a common and reasonable thing to do, so they should work properly.  Only
when the scroll-ups/downs start coming in faster than human typing rate
should we switch to the point moving command.

> > That involves knowing where continuation lines are, possibly where
> > invisible characters are.  And one must take account of
> > next-screen-context-lines, and the like.

> Yes, and the gazillion other scroll-* options.  Did you already try
> your changes with them?  Do you always succeed to scroll as little as
> possible under scroll-conservatively, for example?

Yes, they seem fine.  (That's with the
binding-fontification-functions-to-nil patch.)

> > If I understand correctly, your notion of accuracy in scrolling
> > absolutely requires that all text scrolled over must be fully fontified.

> The display engine must somehow know the exact same metrics of each
> screen line as the line will have when actually displayed.  The only
> way we know how to do that is by "simulating display", which includes
> fontification, yes.

> > I don't see that this makes any sense at all on ttys

> I think we use the same code on TTYs for the simple reason not to
> introduce yet another separate branch in the code, which will then
> have separate bugs etc.

> > and in the very common case that all characters are equally big on a
> > GUI.

> This is IMO anti-thesis of the current GUI display engine.  It was
> _created_ to free us from this assumption, which was considered
> outdated 15 years ago.  It makes very little sense to me to go back to
> this assumption nowadays.

Having variable size fonts is great (possibly essential) for Emacs, but
they create an overhead, and that overhead is imposed on users with no
need for the feature.  It's analogous to font lock - a programmer's
editor without font locking is almost inconceivable today (unlike 20
years ago), but for those who don't want it, we don't impose the
processing overhead on them when they disable it.

> And if you don't assume that, the hard problem is to _know_ when this
> is the case.  We have no way of knowing that, except by scanning the
> buffer.

Allowing the user to decide by setting an option, a bit like we allow her
to turn font-lock mode off.

> And you still didn't reply to my suggestion to use jit-lock-defer-time.
> In my testing, setting it to 0.05 sec is enough to give you what you
> want, for free.  That is just another evidence that we already have
> enough knobs in our arsenal to solve these problems when they annoy
> someone.

If Stefan's suggestion to modify jit-lock-defer so that it only kicks in
when the event-queue is non-empty works, you could be right.

> E.g., I always have jit-lock-stealth turned on, so my buffers are
> always fully fontified, except in the few first moments of a session
> (something that happens rather rarely).  This allows me to avoid the
> problem entirely, without sacrificing accuracy.

I have default jit-lock settings, and power up my machine sometimes
several times a day.  I think customising jit-lock is just too difficult
for most users.  (I find it difficult enough that I don't bother.)

-- 
Alan Mackenzie (Nuremberg, Germany).