Re: emacs-tree-sitter and Emacs

[Eli Zaretskii]

> 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.  I expect that most languages are not like Ada.

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.

> 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".

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.

> >> The elisp manual section "Forcing redisplay" says "Emacs normally tries
> >> to redisplay the screen whenever it waits for input." After I type the
> >> first character, it is no longer waiting for input, it is processing
> >> that character. I assume here "process that char code" includes running
> >> after-change-functions, which is (small) elisp code. But I guess after
> >> processing that char, before calling redisplay, it checks if there is
> >> more input, which should be true if I type fast enough. Perhaps "process
> >> that char code" is faster than the combination of my fingers and the
> >> keyboard char send rate?
> >
> > Yes, most probably.
> 
> Ok, so in practice, it is not possible to type fast enough, and
> font-lock runs after every character typed. 

It's possible.  One situation where this happens is when you have
something expensive running after each command, for example some
expensive post-command-hook.  Another situation is to make your
keyboard's auto-repeat be very fast, and lean on some key.  Yet
another is to run Emacs on an old and not-so-fast machine.