[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: |
Wed, 01 Apr 2020 22:46:18 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> In C or C++ body files, "a complete parse" is typically one variable or
> function declaration. So if Emacs can reliably find the beginning and
> end of those declarations,
IIUC, a large part of CC-mode's trouble is exactly the need to find
somewhat reliably a position vaguely like "the beginning of
a declaration".
It's very much a non-trivial problem (and in the general case to
properly handle all possible comments you need to start parsing from
point-min).
>> And yes, doing this by consing strings is not a good idea, it will
>> slow things down and cause a lot of GC. It is best avoided. Thus my
>> questions above.
> I'm not sure how "convert syntax tree to elisp" compares to "consing
> strings". I would certainly expect it to cause a lot of GC.
If the GC is the worry, we can use a function which encodes the
buffer using a given coding-system and returns a malloc'd array of bytes.
>>> It's stored in a buffer-local variable. I haven't measured the memory
>>> they take. Memory is released when the tree object is garbage-collected
>>> (it's a `user-ptr').
> Is it an elisp structure (or accesible from elisp)? Have you written
> code that traverses it to provide faces and indentation?
According to https://github.com/tree-sitter/tree-sitter/issues/222 the
parse tree takes around 10 times the size of the source text. At least
that's for tree-sitter's own parse-tree; not sure how that relates to
emacs-tree-sitter's yet.
Stefan
- Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), (continued)
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), 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 <=
- 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, 2020/04/02
- 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