Re: emacs-tree-sitter and Emacs

[Stephen Leake]

Eli Zaretskii <address@hidden> writes:

>> From: Stephen Leake <address@hidden>
>> Date: Thu, 02 Apr 2020 17:55:36 -0800
>> 
>> > But why do you need that initial full parse in the first place?  Is
>> > parsing parts of the buffer so much harder?
>> 
>> Because the parser must see a complete top level grammar statement. In
>> Ada, that's the whole file; a typical file looks like:
>
> OK, so this depends on the language, and is not a universal
> requirement.  

Yes.

> the point I think we should take from this is that the font-lock
> infrastructure should not _force_ the parser to always perform a full
> parse, it should delegate that to the parser or to a language-aware
> layer that calls the parser.

Yes.

>> Use case: A c-mode buffer A is currently displayed in a window in a
>> frame, it is syntactically correct, and all displayed faces are correct.
>> In another frame, the user uses 'M-x set-variable' to change the value
>> of font-lock-function-name-face.
>> 
>> To update the display, something has to trigger redisplay of buffer A. I
>> don't think using M-x set-variable in a different frame does that.
>
> That's not so.  Redisplay is called every time Emacs is about to
> become idle.  It just returns almost immediately if it detects that no
> changes happened since last redisplay that require any work.  I guess
> this fast return is what you mean by "not triggering redisplay".

Ok.

> Regarding the above use case, I don't think I understand what exactly
> did you mean.  First, you cannot use set-variable to modify the value
> of font-lock-function-name-face, because it isn't a defcustom.
> Second, what exactly did you mean to set it to, to cause the effect
> you were talking about?  IOW, can you present a complete recipe,
> starting from "emacs -Q", where you make such a change, and then you
> need to switch buffers to cause function names be displayed
> differently?  I can tell you that if you replace "M-x set-variable"
> with "M-x customize-face" and change some attribute of
> font-lock-function-name-face, the effect on another frame is
> immediate, which means redisplay takes note of the change and redraws
> the other frame.  But I'm not sure this is the same use case you had
> in mind.

Ok. In this case, customize-face causes the redisplay. So your original
objection to the ada-mode face design, which was:

> And they cannot pick up every relevant change; for example, what
> happens if some face used for font-lock is modified?

is moot. Unless some elisp program modifies the variable without using
customize-face, but then that program has the responsibility for forcing
redisplay.

If there are other things that can be changed that should force a
redisplay, but currently don't, I would say that's a bug, either in
ada-mode or elsewhere. So far there have been no bugs filed against
ada-mode for this type if issue.

-- 
-- Stephe