emacs-devel
[Top][All Lists]
Advanced

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

Re: cc-mode fontification feels random


From: martin rudalics
Subject: Re: cc-mode fontification feels random
Date: Sun, 13 Jun 2021 11:39:55 +0200

>> The idea is good but still not what I want.  I don't want the entire
>> rest of my buffer get refontified even when I do not stay on the same
>> line.
>
> Right.  I was  strictly addressing your description of adding a single
> quote and then watching the whole buffer repaint itself.  If one does other
> editing or movement actions after that, then antiblink throws in the towels
> and says "all bets are off, better not assume more things about the user's
> fontification intentions".
>
> That's because maybe you _do_ want the whole buffer to be refontified
> and are intending to go to some point up to EOB to put the closing quote.

I admit that this probably meets most users' intentions.  What I do not
understand about its implementation is that if `jit-lock-contextually'
is t (as it is usually set by `jit-lock-register'), you unconditionally
add the antiblink mechanism to `post-command-hook' which IIUC causes a
`syntax-ppss' call unconditionally getting run for each command even
when `jit-lock-antiblink-grace' is nil.  Is that perception correct?  If
so, I think that you should not do that.

> Regardless, I would file a bug if I saw that behaviour :-) ,

... even with `open-paren-in-column-0-is-defun-start' non-nil?

> because it might
> be my sincere intention to have the buffer be repainted.  I could be composing
> a docstring or an example where an opening parenthesis happens to
> have fallen on the first column of a line.
>
> In fact I seem to remember that in SLIME or SLY that is already problematic
> when evaluating a chunk of code where a docstring happens to have that
> quirk.   And that it is because of open-paren-at-column-0-is-defun-start.

But `open-paren-in-column-0-is-defun-start' is a customizable variable.
Which means that a user should be able to use it to control the behavior
of Emacs in this regard.  And it is t by default for no obvious reason.

> In another ISTR moment, ISTR that other editors do the same as Emacs
> does here , i.e. repaint. I haven't seen an equivalent to antiblink.

martin



reply via email to

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