Re: emacs rendering comparisson between emacs23 and emacs26.3

[Alan Mackenzie]

Hello, Eli.

On Wed, Apr 08, 2020 at 09:15:49 +0300, Eli Zaretskii wrote:
> > Date: Tue, 7 Apr 2020 20:10:18 +0000
> > Cc: Dmitry Gutov <address@hidden>, address@hidden, address@hidden,
> >   address@hidden, address@hidden
> > From: Alan Mackenzie <address@hidden>

> > OK, I'm on Line 8759, where I've got:

> >   else
> >     cp->status = STATUS_READ_FAILED;

> > (I haven't updated for a few days.)  Is this the same place?

> Yup.

> > > FTR, this is in Emacs 27.0.90 built with -Og, but a -O2 compilation of
> > > Emacs 26.3 takes only slightly less time in this case.

> > Is this not jit-lock-context-time?

> I have no idea.  But if you are saying that this is "normal", then I
> disagree: I don't see why the change in fontification after DEL is
> instantaneous, while the change after typing 'e' takes such annoyingly
> long time.  Is jit-lock-context-time not involved in the former? if
> so, why?

Is the problem more the asymmetry between the deletion and the
insertion than the actual time taken after the reinsertion?  We've had
context fontification since Emacs 21.

I admit I don't remember in detail why after the deletion the font
locking region is extended, but not after the reinsertion.  Possibly in
the former case, context fontification failed to do the job right.

> > However, first setting font-lock-support-mode to nil, then
> > reinitialising font-lock, deleting then reinserting that "e", the line
> > after the else _never_ gets its (lack of) face back.

> So this is still rather a mystery, isn't it?

It's context fontification.  I'm quite sure of that, now.  To restart
jit-lock with a new j-l-context-time involves explicitly getting rid of
a timer and allowing it to restart.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).