emacs-devel
[Top][All Lists]
Advanced

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

Re: emacs-tree-sitter and Emacs


From: Stephen Leake
Subject: Re: emacs-tree-sitter and Emacs
Date: Fri, 03 Apr 2020 09:24:38 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (windows-nt)

Eli Zaretskii <address@hidden> writes:

>> >> I would think that you at least need to parse everything displayed and
>> >> everything before what is displayed.  (You need all prior context.  What
>> >> if someone opened a comment on line 1 and hasn't closed it, for
>> >> example?)
>> >
>> > Each buffer always knows which part of it remains unchanged.  
>> 
>> Only because jit-lock-after-change on after-change-functions updates
>> that knowledge, via the fontified text property. But that in turn
>> assumes that the entire buffer has been fontified, which is typically
>> not the case; I rarely scroll thru an entire file.
>> 
>> Unless there is some other mechanism that maintains change locations?
>
> I meant BEG_UNCHANGED and END_UNCHANGED.

Ah; I was unaware of those. It would be good if these values were
accessible from modules and elisp. That might remove the need for
ada-mode's after-change-functions; I'd have to try it to be sure.
For one thing, ada-mode maintains a list of changed regions, while this
lumps them all together, and includes unchanged text in between. That
would trigger parses that are not actually needed, but that might be a
good trade.

Hmm. Browsing the emacs C source to see if there is such a function (I
didn't find one, but I could have missed it), I found this in keyboard.c:

      /* If the previous command tried to force a specific window-start,
         forget about that, in case this command moves point far away
         from that position.  But also throw away beg_unchanged and
         end_unchanged information in that case, so that redisplay will
         update the whole window properly.  */

    BUF_BEG_UNCHANGED (b) = BUF_END_UNCHANGED (b) = 0;

which means BEG_UNCHANGED can indicate changes when there are actually
none. As long as that doesn't happen too often, it's acceptable.

-- 
-- Stephe



reply via email to

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