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: Thu, 02 Apr 2020 18:06:40 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (windows-nt)

Eli Zaretskii <address@hidden> writes:

>> From: Michael Welsh Duggan <address@hidden>
>> Cc: Stephen Leake <address@hidden>,  address@hidden
>> Date: Thu, 02 Apr 2020 10:27:23 -0400
>> 
>> > But why do you need that initial full parse in the first place?  Is
>> > parsing parts of the buffer so much harder?
>> 
>> 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?
There is buffer-modified-p, but that's a single binary for the whole
buffer. ada-mode has one; it also uses after-change-functions.

> When fontification is invoked, it should start from that place. 

I think you mean "from the point of the first change" which means "from
the first point where fontified is nil". But that's not what font-lock
does; it starts from the current top of window if that's after the first
non-fontified point.

-- 
-- Stephe



reply via email to

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