[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reliable after-change-functions (via: Using incremental parsing in E
From: |
Tuấn-Anh Nguyễn |
Subject: |
Re: Reliable after-change-functions (via: Using incremental parsing in Emacs) |
Date: |
Thu, 2 Apr 2020 11:36:20 +0700 |
> 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.
>
If we are talking about a function exposed to dynamic modules, then we
will also need to expose another function to free that byte array,
because the dynamic module may use a different allocator. It's probably
better to ask the caller to prepare that array, like what
`copy_string_contents' does.
> >>> 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.
>
emacs-tree-sitter adds 16 bytes for reference counting and 8 bytes for
checking concurrent modifications (because nodes are also exposed to
Lisp as objects). That's negligible I think.
--
Tuấn-Anh Nguyễn
Software Engineer
- 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, 2020/04/01
- Re: Reliable after-change-functions (via: Using incremental parsing in Emacs),
Tuấn-Anh Nguyễn <=
- 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
- Re: [SPAM UNSURE] Re: Reliable after-change-functions (via: Using incremental parsing in Emacs), Robert Pluim, 2020/04/03