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: Michael Welsh Duggan
Subject: Re: emacs-tree-sitter and Emacs
Date: Thu, 02 Apr 2020 14:50:18 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Michael Welsh Duggan <address@hidden>
>> Cc: <address@hidden>, <address@hidden>, <address@hidden>
>> Date: Thu, 02 Apr 2020 12:19:44 -0400
>> 
>> >> > Each buffer always knows which part of it remains unchanged.  When
>> >> > fontification is invoked, it should start from that place.  So there's
>> >> > no need to parse _all_ prior context.
>> >> 
>> >> Why not?  Won't it miss that hypothetical opening comment delimiter, for
>> >> example?
>> >
>> > No, because that was already taken care of when that comment delimiter
>> > was inserted.
>> 
>> In which case it's covered by the paragraph you omitted.
>
> I don't think it is, because you were talking about parsing the full
> buffer, whereas I'm talking about parsing only what affects the
> display in the window.

No, not really.  Though I think it's just miscommunication on my end.
Let me sum up what I believe has been said.  I don't claim to be correct
in any of this, but it is what I believe is the current set of facts:

In normal usage, these external parsers are supposed to work like this:

1) Parse the whole file.  (This is a step that I believe you'd like to
   avoid, but I'm talking about how it is intended to work right now.)

2) At this point the parser holds a parse tree and can be asked
   questions about syntactic information about any portion of the
   buffer.

3) Subsequently any change to the buffer is sent to the parser (just the
   change) which updates its view of the world and it's internal parse
   state.  

4) After each change, the parse might communicate some of its syntactic
   information back to the program using it, or it might just wait for
   the program to ask more questions.  Of this, I am uncertain.

If this is correct, I also think we could avoid (1) as an optimization.
In this case we only send the text from (save-restriction (widen)
(point-min)) to (window-end) to the parser as soon as the buffer is
visible.  Then treat scrolling down as a change that adds text to the
buffer (from the parser's point of view).  This may not produce correct
semantic information in all cases, but it is probably a reasonable first
approximation in the event that we want to avoid (1).  If we were to do
this, we would probably want to make this configurable.

Now that I have hopefully communicated my understanding, now people can
express how I have misunderstood and/or just gotten this completely
wrong.  Which is just fine, and hopefully I will have learned something
in the process.

-- 
Michael Welsh Duggan
(address@hidden)



reply via email to

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