GNU bug report logs - #62333
30.0.50; Issue with tree-sitter syntax tree during certain changes

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: wkirschbaum <at> gmail.com, gregory <at> heytings.org, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org
Subject: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes
Date: Fri, 31 Mar 2023 04:10:54 +0300

On 29/03/2023 14:08, Eli Zaretskii wrote:
>> Date: Wed, 29 Mar 2023 00:08:53 +0300
>> Cc: wkirschbaum <at> gmail.com, gregory <at> heytings.org, casouri <at> gmail.com,
>>   62333 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>>>> Is that because we don't think the user level narrowing is done purely
>>>> for visual effect?
>>>
>>> Indeed, it isn't always for visual effect.
>>
>> When isn't it? Is there a way to determine that from code?
> 
> I'm not sure I understand the question, but if I do, then narrowing to
> prevent search functions

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.

> and commands from finding irrelevant hits is
> one example that comes to mind.

More or less the same, except we have the user option 
widen-automatically, which apparently (?) allows any command to "widen 
when they want to"?

Used by popular demand in e.g. xref--goto-char. And IIUC 'find-tag' just 
always calls 'widen' irrespective of this variable's value.

>>>> judging by regular user requests for make this or that command
>>>> ignore user-level narrowing, it seems like "purely visual" should be the
>>>> default interpretation.
>>>
>>> I think you base your judgment on feedback from users who are not used
>>> to take advantage of narrowing in editing.  I think most young people
>>> aren't, since this feature is more-or-less unique to Emacs.
>>
>> 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.
> 
> 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'.

But none of that describes how other Emacs features should react to it.

Simple example: if the beginning of the narrowed region falls inside a 
(let's say multine) string, should the visible remainder of that string 
continue to be highlighted as a string? Or should the buffer contents 
after the string's closer now be highlighted as being inside a string?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.