From: Eli Zaretskii <eliz@gnu.org>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: casouri@gmail.com, emacs-devel@gnu.org
Subject: Re: Exposing buffer text modifications to Lisp
Date: Tue, 21 Jun 2022 15:27:27 +0300 [thread overview]
Message-ID: <831qvikxqo.fsf@gnu.org> (raw)
In-Reply-To: <87wndar5tt.fsf@localhost> (message from Ihor Radchenko on Tue, 21 Jun 2022 12:36:14 +0800)
> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: casouri@gmail.com, emacs-devel@gnu.org
> Date: Tue, 21 Jun 2022 12:36:14 +0800
>
> > OTOH, don't you want to create a Lisp structure to represent AST? If
> > so, C-level tree will not really help you, would it?
>
> Clarification: I was asking about C-level trees to store marker list.
> I did not have moving Org AST from Lisp to C-level in mind. We currently
> use built-in Lisp implementation of AVL-tree to search across AST (which
> is not ideal, but good enough for moderately large files).
Ah, okay. Sorry for my misunderstanding.
Trees could indeed be relevant, but maybe other data structures as
well? E.g., why not hash tables? Not that I consider myself an
expert on efficient search algorithms...
> For example, consider
>
> * TODO headline
>
> being changed into
>
> * DONE headline
>
> with (with-silent-modifications (search-foward "TODO") (replace-match "DONE"))
> or even simply by (replace-match ...) inside indirect buffer created by
> direct call to make-indirect-buffer.
>
> The AST headline object will need to be updated from
> (headline (... :todo-keyword "TODO" ...))
> to
> (headline (... :todo-keyword "DONE" ...))
>
> > Emacs inhibits buffer-modification hooks when
> > it is quite sure Lisp programs "don't need to know" about those
> > modifications. One example you cited where this bites you is use of
> > input methods. But Quail doesn't inhibit the hooks completely, it
> > only inhibits them enough to pretend that just one character was
> > inserted, when the user might have inserted more. So why does this
> > get in the way of the Org parser, if the modification hooks are being
> > called "enough"?
>
> It does not. Given that I implement the suggestion about using
> buffer-size to track "missed" modifications, Quail will not be an issue
> anymore.
>
> The only potential problem that will remain is the type of buffer
> modifications I described above (shielded by inhibit-modification-hooks
> or by being done inside indirect buffer). If such modifications do not
> change the buffer size (as above), we still get a problem that may
> (although less likely) cause data loss on user side.
I'd consider such Lisp programs buggy. Actually modifying a buffer
while concealing the entire modification is evil.
> I will submit patches via debbugs in future to make things more
> visible.
TIA.
next prev parent reply other threads:[~2022-06-21 12:27 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-19 1:35 Tree-sitter integration on feature/tree-sitter Kiong-Ge Liau
2022-05-20 2:01 ` Yuan Fu
2022-06-16 19:03 ` Yuan Fu
2022-06-16 19:25 ` [External] : " Drew Adams
2022-06-17 1:11 ` Yuan Fu
2022-06-17 14:22 ` Drew Adams
2022-06-17 1:24 ` Po Lu
2022-06-18 0:09 ` Yuan Fu
2022-06-17 2:00 ` Ihor Radchenko
2022-06-17 2:25 ` Lower-level change hook immune to with-silent-modifications Yuan Fu
2022-06-17 2:55 ` Stefan Monnier
2022-06-17 5:28 ` Eli Zaretskii
2022-06-17 10:10 ` Ihor Radchenko
2022-06-17 11:03 ` Eli Zaretskii
2022-06-17 5:23 ` Tree-sitter integration on feature/tree-sitter Eli Zaretskii
2022-06-17 10:40 ` Ihor Radchenko
2022-06-17 11:42 ` Exposing buffer text modifications to Lisp (was: Tree-sitter integration on feature/tree-sitter) Eli Zaretskii
2022-06-18 5:52 ` Ihor Radchenko
2022-06-18 7:01 ` Eli Zaretskii
2022-06-18 7:23 ` Ihor Radchenko
2022-06-18 7:44 ` Eli Zaretskii
2022-06-18 8:13 ` Ihor Radchenko
2022-06-18 8:47 ` Exposing buffer text modifications to Lisp Eli Zaretskii
2022-06-20 11:58 ` Ihor Radchenko
2022-06-20 12:32 ` Eli Zaretskii
2022-06-20 14:14 ` Stefan Kangas
2022-06-21 3:56 ` Ihor Radchenko
2022-06-21 4:36 ` Ihor Radchenko
2022-06-21 12:27 ` Eli Zaretskii [this message]
2022-06-25 4:47 ` Optimizing performance of buffer markers (was: Exposing buffer text modifications to Lisp) Ihor Radchenko
2022-06-25 8:29 ` Optimizing performance of buffer markers Stefan Monnier
2022-06-25 8:44 ` Eli Zaretskii
2022-06-25 9:07 ` Stefan Monnier
2022-06-25 9:20 ` Eli Zaretskii
2022-06-25 9:27 ` Stefan Monnier
2022-06-25 9:47 ` Ihor Radchenko
2022-06-25 9:53 ` Stefan Monnier
2022-06-26 10:32 ` Robert Pluim
2022-06-22 15:45 ` Exposing buffer text modifications to Lisp Basil L. Contovounesios
2022-06-22 16:13 ` Eli Zaretskii
2022-06-25 4:54 ` Ihor Radchenko
2022-06-25 5:46 ` Eli Zaretskii
2022-06-29 12:24 ` Ihor Radchenko
2022-06-20 14:33 ` Alan Mackenzie
2022-06-21 3:58 ` Ihor Radchenko
2022-06-17 6:15 ` Tree-sitter integration on feature/tree-sitter Eli Zaretskii
2022-06-17 7:17 ` Yuan Fu
2022-06-17 10:37 ` Eli Zaretskii
2022-06-18 0:14 ` Yuan Fu
2022-06-18 6:22 ` Eli Zaretskii
2022-06-18 8:25 ` Yuan Fu
2022-06-18 8:50 ` Eli Zaretskii
2022-06-18 20:07 ` Yuan Fu
2022-06-19 5:39 ` Eli Zaretskii
2022-06-20 3:00 ` Yuan Fu
2022-06-20 11:44 ` Eli Zaretskii
2022-06-20 20:01 ` Yuan Fu
2022-06-21 2:26 ` Eli Zaretskii
2022-06-21 4:39 ` Yuan Fu
2022-06-21 10:18 ` Eli Zaretskii
2022-06-22 0:34 ` Yuan Fu
2022-06-17 11:06 ` Jostein Kjønigsen
2022-06-18 0:28 ` Yuan Fu
2022-06-18 20:57 ` Jostein Kjønigsen
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=831qvikxqo.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=casouri@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=yantar92@gmail.com \
/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).