emacs-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Re: cc-mode fontification feels random


From: Eli Zaretskii
Subject: Re: [PATCH] Re: cc-mode fontification feels random
Date: Tue, 31 Aug 2021 14:53:04 +0300

> Date: Mon, 30 Aug 2021 20:03:01 +0000
> Cc: dancol@dancol.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > So you are saying that this will cause the display of the visible
> > portion of the window to flicker whenever jit-lock-stealth finds such
> > a "new type"?
> 
> There will be a one-time change from no fontification of foo to
> font-lock-type-face.  The actual area of the screen getting refontified
> is one declaration.
> 
> > That could annoy, can't it?
> 
> It might.  It didn't annoy me whilst trying it out.  The real question
> is, will it annoy less than having types permanently unfontified.

I don't think we will know soon enough.  Which is why I think this
should be optional behavior.

> > jit-lock-stealth is for fontifying portions of the buffer(s) that are
> > not on display, it would be wrong for it to apply this enhancement, I
> > think, certainly by default.
> 
> jit-lock has a presumption that the fontification of one part of a buffer
> doesn't influence the fontification of another part.

More accurately, that fontification of some part doesn't affect the
parts of the buffer before that.

> My impression is that jit-lock isn't much used.  It's disabled by
> default.  What I'm envisaging is repurposing it to solve a real problem.

As one user who uses jit-stealth-lock all the time, I don't think it's
wise to make jit-stealth-lock do this additional job by default.  They
are two separate jobs, and the optimal values of parameters that
control jit-stealth-lock are different for each job.  So this
re-purposing shouldn't be unconditional, IMO.

> > And jit-lock-stealth-time of 1 sec is too short.  I use 16, because
> > once jit-lock-stealth starts fontifying a chunk, Emacs can be
> > relatively slow to react to keyboard input, so I prefer to let
> > jit-lock-stealth start its thing only when there's a very good chance
> > I indeed stopped typing, not just thinking about something for a
> > second or two.
> 
> On my first try this evening with jit-lock, I set jit-lock-stealth-nice
> to zero.  I completely lost control of my session, and hat to abort it
> and restart.

Of course, you aren't supposed to do that.

> But with the parameters set appropriately, can stealth really make
> Emacs slow to react?

IME, yes, because we our way of interrupting a Lisp program is not
quick enough in some real-life situations.

> Well, I was thinking of these enhancements to stealth being more of an
> option than forced upon people.  For example, a new variable
> jit-lock-stealth-time-block could be nil by default, or set to 0.05 to
> fontify for 0.05 seconds before attending to user input.

IME, 0.05 sec is already borderline for good responsiveness UX.

> > If you want that, you can easily arrange for Emacs to behave like that
> > without changing any code.
> 
> I didn't see any way of doing it while looking at the code earlier on.
> What exactly are you thinking of, here?

Lower jit-lock-stealth-nice and jit-lock-stealth-time to small
values.  Optionally, enlarge jit-lock-chunk-size as well.



reply via email to

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