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

Previous Next

Full log

Message #161 received at 62333 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during
 certain changes
Date: Wed, 29 Mar 2023 00:08:53 +0300

On 28/03/2023 14:32, Eli Zaretskii wrote:
>> Date: Tue, 28 Mar 2023 02:06:17 +0300
>> Cc: wkirschbaum <at> gmail.com, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> On 27/03/2023 16:39, Eli Zaretskii wrote:
>>>> Date: Mon, 27 Mar 2023 08:24:42 +0000
>>>> From: Gregory Heytings<gregory <at> heytings.org>
>>>> cc: Eli Zaretskii<eliz <at> gnu.org>,wkirschbaum <at> gmail.com,casouri <at> gmail.com,
>>>>       62333 <at> debbugs.gnu.org
>>>>
>>>>>> Which is a fragile, semi-broken means, as we all know.
>>>>> What is a broken mess, is user-level narrowing. And how the downstream
>>>>> code can never guess the purpose the narrowing was applied for.
>>>> Note that this is what labeled narrowings attempts to solve.
>>> Labeled narrowing cannot solve this because it does nothing to
>>> alleviate the problems with user-defined narrowing.  So if the user
>>> narrows the buffer, we cannot do anything to safely widen in the
>>> general case, and labeled narrowing cannot help us.
>>
>> 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?

>> 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.

Previous Next

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