[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reliable after-change-functions (via: Using incremental parsing in E
From: |
Stefan Monnier |
Subject: |
Re: Reliable after-change-functions (via: Using incremental parsing in Emacs) |
Date: |
Thu, 02 Apr 2020 11:19:33 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> I think we should try to avoid both copying and encoding the text we
> send to the parser. Both operations are expensive and require memory
> allocation.
I think both operations are cheap enough relatively to the actual
parsing that it is not indispensable to avoid them: maybe it will be
worth the effort, but maybe not.
In any case, it's a minor implementation detail that can easily be
changed in the future without impacting the rest of the code.
So, I think it falls squarely in the realm of premature optimization.
>> According to https://github.com/tree-sitter/tree-sitter/issues/222 the
>> parse tree takes around 10 times the size of the source text.
> Yes, that's another reason why it might make sense to "forget" trees
> of buffers that were not displayed for a long time.
Agreed, tho I wouldn't word it that way: parse trees are not needed for
redisplay and can be used for things that don't relate to redisplay
(e.g. navigation, indentation, ...).
> But this is an optimization that can be added later without any
> significant changes in the design.
Agreed as well.
Stefan
- Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), (continued)
- Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Eli Zaretskii, 2020/04/01
- Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Tuấn-Anh Nguyễn, 2020/04/01
- Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Eli Zaretskii, 2020/04/01
- Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Stephen Leake, 2020/04/01
- Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Stephen Leake, 2020/04/01
- Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Stefan Monnier, 2020/04/01
- Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Tuấn-Anh Nguyễn, 2020/04/02
- Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Eli Zaretskii, 2020/04/02
- Re: Reliable after-change-functions (via: Using incremental parsing in Emacs),
Stefan Monnier <=
- Re: [SPAM UNSURE] Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Stephen Leake, 2020/04/02
- Re: [SPAM UNSURE] Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Eli Zaretskii, 2020/04/03
- Re: [SPAM UNSURE] Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Stephen Leake, 2020/04/03
- Re: [SPAM UNSURE] Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Eli Zaretskii, 2020/04/03
- Re: [SPAM UNSURE] Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Stephen Leake, 2020/04/03
- Re: [SPAM UNSURE] Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Robert Pluim, 2020/04/03
- Re: [SPAM UNSURE] Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Eli Zaretskii, 2020/04/03
- Re: [SPAM UNSURE] Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Robert Pluim, 2020/04/03
- Re: [SPAM UNSURE] Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Eli Zaretskii, 2020/04/03
- Re: [SPAM UNSURE] Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), John Yates, 2020/04/03