all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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>





  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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.