[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
- Re: emacs-tree-sitter and Emacs, (continued)
- Re: emacs-tree-sitter and Emacs, Eli Zaretskii, 2020/04/02
- Re: emacs-tree-sitter and Emacs, Eli Zaretskii, 2020/04/02
- Re: emacs-tree-sitter and Emacs, Michael Welsh Duggan, 2020/04/02
- Re: emacs-tree-sitter and Emacs, Eli Zaretskii, 2020/04/02
- Re: emacs-tree-sitter and Emacs, 조성빈, 2020/04/02
- Re: emacs-tree-sitter and Emacs, Eli Zaretskii, 2020/04/03
- Re: emacs-tree-sitter and Emacs, Stephen Leake, 2020/04/03
- Re: emacs-tree-sitter and Emacs, Stefan Monnier, 2020/04/02
- Re: emacs-tree-sitter and Emacs, Stephen Leake, 2020/04/02
- Re: emacs-tree-sitter and Emacs, Eli Zaretskii, 2020/04/03
- Re: emacs-tree-sitter and Emacs,
Stephen Leake <=
- Re: emacs-tree-sitter and Emacs, Eli Zaretskii, 2020/04/03
- Re: emacs-tree-sitter and Emacs, martin rudalics, 2020/04/02
- Re: emacs-tree-sitter and Emacs, Stephen Leake, 2020/04/02
- Re: emacs-tree-sitter and Emacs, Jorge Javier Araya Navarro, 2020/04/03
- Re: emacs-tree-sitter and Emacs, Eli Zaretskii, 2020/04/03
- Re: emacs-tree-sitter and Emacs, Stephen Leake, 2020/04/03
- Re: emacs-tree-sitter and Emacs, Eli Zaretskii, 2020/04/03
- Re: emacs-tree-sitter and Emacs, Stephen Leake, 2020/04/03
Re: emacs-tree-sitter and Emacs, Stefan Monnier, 2020/04/01