From: Ihor Radchenko <yantar92@posteo.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Yuan Fu <casouri@gmail.com>, 65451@debbugs.gnu.org
Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made
Date: Tue, 22 Aug 2023 13:41:17 +0000 [thread overview]
Message-ID: <87v8d7i48y.fsf@localhost> (raw)
In-Reply-To: <834jkrters.fsf@gnu.org>
Eli Zaretskii <eliz@gnu.org> writes:
>> Then, I'd like to point back to the previous discussion where I asked to
>> expose to Elisp information about buffer changes available to
>> tree-sitter.
>> https://yhetil.org/emacs-devel/83tu8jq2vl.fsf@gnu.org/
>
> I don't want to do that, sorry. Not without a good understanding of
> what exactly do you need from that and in what way. If we will expose
> anything, it will have to be the minimum possible exposure, not the
> maximum, so I would like to understand this very well before I agree
> to any change in this direction.
Org wants to do the same thing tree-sitter does - keep parsed AST in
sync with buffer modifications without having to re-parse the whole
buffer. So, we basically need the same information tree-sitter needs -
the sequence of buffer text changes, in their order.
Note that the markers discussed in the thread I linked are not
sufficient. When editing near AST node boundaries, even if the
boundaries are represented by markers, we have to re-parse the AST
around to account for the possible structural changes. So, information
about buffer edits is still required.
>> In fact, I am not sure if tree-sitter will behave correctly if it is
>> signaled changes in incorrect order.
>
> I will defer to Yuan, but tree-sitter doesn't use these hooks, we call
> its functions directly from insdel.c where needed. This makes sense
> for a library to which we link and whose interface code we control,
> but giving such access to Lisp (and Org on top of that) is out of the
> question. We don't even give such access to modules.
I hope that we can solve this issue one way or another. This currently
breaks the very core functionality of Org. Every part of Org relies on
it to obtain reasonable performance. Prior to using cache, we had orders
of magnitude slowdowns.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2023-08-22 13:41 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-22 9:30 bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Ihor Radchenko
2023-08-22 12:22 ` Eli Zaretskii
2023-08-22 12:42 ` Ihor Radchenko
2023-08-22 12:58 ` Eli Zaretskii
2023-08-22 13:41 ` Ihor Radchenko [this message]
2023-08-22 16:02 ` Eli Zaretskii
2023-08-23 8:52 ` Ihor Radchenko
2023-08-23 17:58 ` Eli Zaretskii
2023-08-24 7:46 ` Ihor Radchenko
2023-08-24 8:08 ` Eli Zaretskii
2023-08-24 11:24 ` Ihor Radchenko
2023-08-24 12:08 ` Eli Zaretskii
2023-08-24 13:27 ` Ihor Radchenko
2023-08-24 14:53 ` Eli Zaretskii
2023-08-25 6:37 ` Eli Zaretskii
2023-08-25 9:09 ` Ihor Radchenko
2023-08-26 7:10 ` Eli Zaretskii
2023-08-27 8:13 ` Ihor Radchenko
2023-08-27 8:29 ` Eli Zaretskii
2023-08-29 7:39 ` Ihor Radchenko
2023-08-25 8:09 ` Ihor Radchenko
2023-08-25 10:25 ` Eli Zaretskii
2023-08-25 10:49 ` Ihor Radchenko
2024-03-30 13:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 14:11 ` Eli Zaretskii
2024-03-30 15:38 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 16:47 ` Eli Zaretskii
2024-03-31 3:04 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 3:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 6:06 ` Eli Zaretskii
2024-03-31 13:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 18:19 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-08 19:10 ` Ihor Radchenko
2024-04-07 18:19 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v8d7i48y.fsf@localhost \
--to=yantar92@posteo.net \
--cc=65451@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).