all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Yuan Fu <casouri@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, 59693@debbugs.gnu.org, miha@kamnitnik.top
Subject: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly
Date: Sun, 04 Dec 2022 22:49:14 -0500	[thread overview]
Message-ID: <jwvpmcyedsr.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <BB326ABB-F0A5-4A08-9C53-7AE738588932@gmail.com> (Yuan Fu's message of "Thu, 1 Dec 2022 21:05:43 -0800")

> Actually there’s a little bit of problem. When we edit the base buffer, we
> would want to update the parsers in all of its indirect buffers as well, and
> AFAICT there is no pointer from base buffer to the indirect buffer, only the
> other way around. 

Background note: I consider indirect buffers an attractive nuisance
and for this reason I think we should spend as little time as possible
improving them.  Instead we should encourage people to develop
alternative approaches.
I know we have a large number of bugs lurking in that area.

E.g.:

    Emacs -Q
    M-x clone-indirect-buffer RET
    M-x fundamental-mode RET

we see that `*scratch*` has lost its font-lock highlighting even though we
changed major mode in the "other" buffer.
Now go to `*scratch*` type some text: you see that font-lock properly
updates the new code's highlighting.
Then go to `*scratch*<2>` and type some more text: you should see that
font-lock does *not* properly update the new code's highlighting in the
base buffer.

AFAICT this is the exact same bug as what you're seeing, just with
font-lock instead of tree-sitter.  [ Of course, for font-lock it's worse
because font-lock uses text-properties (which are shared between the
base and the its indirect buffers) so it simply can't do its job
properly in indirect buffers.  ]

This bug has been with us since indirect buffers were invented, so
it has very low priority, AFAIC.

> Then base buffer can update all indirect buffers’ parsers, and indirect
> buffer can find its base buffer and update all the parsers, including the
> base buffer’s parsers and other indirect buffers’ parsers.

Don't bother, please.
Instead, I recommend you disallow the use of tree sitter in indirect
buffers.  And we should probably try and change `insdel.c` so it always
runs the `after/before-change-functions` in the base buffer (this should
fix the worst part of the problems).


        Stefan






  parent reply	other threads:[~2022-12-05  3:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-29 20:21 bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-30 10:17 ` Yuan Fu
2022-11-30 14:05   ` Eli Zaretskii
2022-12-02  5:05     ` Yuan Fu
2022-12-02  8:33       ` Eli Zaretskii
2022-12-03  1:01         ` Yuan Fu
2022-12-04  7:20           ` Yuan Fu
2022-12-04  7:46             ` Eli Zaretskii
2022-12-04 23:21               ` Yuan Fu
2022-12-05  3:49       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-12-05  8:19         ` Eli Zaretskii
2022-12-05 15:29           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-05 15:44             ` Eli Zaretskii
2022-12-05 20:14               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-06  2:15               ` Yuan Fu
2022-12-06  3:57                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-06 12:17                 ` Eli Zaretskii
2022-12-07 23:13                   ` Yuan Fu
2022-12-08  6:47                     ` Eli Zaretskii
2022-12-10  1:41 ` Yuan Fu

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=jwvpmcyedsr.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=59693@debbugs.gnu.org \
    --cc=casouri@gmail.com \
    --cc=eliz@gnu.org \
    --cc=miha@kamnitnik.top \
    --cc=monnier@iro.umontreal.ca \
    /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.