GNU bug report logs -
#62333
30.0.50; Issue with tree-sitter syntax tree during certain changes
Previous Next
Full log
Message #224 received at 62333 <at> debbugs.gnu.org (full text, mbox):
On 31/03/2023 09:19, Eli Zaretskii wrote:
>> If we're talking about isearch, then that seems like a natural
>> consequence of visual effect (hiding the remainder of the buffer): even
>> if isearch highlighted those other hits, they would not be visible.
> If you consider narrowing in this example to be "for visual effect",
> then everything in Emacs is "for visual effect". After all, Emacs is
> a visual editor, showing the results of editing to the user at all
> times. But this POV makes this part of the discussion useless.
Okay, let's rephrase that: instead of "visual effect", we can say it's
for "visually hiding" parts of buffers. But not for changing their
behaviors otherwise (e.g. changing syntax highlighting, etc).
In your other answer regarding the inside of a string, you seemed to
have a different idea, though. Like, user narrowing would be able to
affect all that stuff too.
>>> I was talking about user commands that narrow, so I'm not sure I
>>> understand how documentation could help. When the user types "C-x n n",
>>> there's nothing Emacs can do except obey.
>> There is really only one main user command that narrows, and that's
>> narrow-to-region, bound to 'C-x n n'.
> Any user command can narrow as part of its job.
This subthread goes back to my complaint that commands don't know how to
*interpret* the current narrowing, thus which effects it should have.
To repeat:
Either narrowing should be used to change lexical/grammatical/etc
context, or it should not. Do we have any documentation that says one
or the other way? That should affect how Lisp code deals with
narrowing -- which interactive functions should widen, and so on.
This bug report was last modified 2 years and 77 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.