GNU bug report logs -
#62333
30.0.50; Issue with tree-sitter syntax tree during certain changes
Previous Next
Full log
Message #233 received at 62333 <at> debbugs.gnu.org (full text, mbox):
On 31/03/2023 16:03, Eli Zaretskii wrote:
>> Date: Fri, 31 Mar 2023 15:38:33 +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>
>>
>> On 31/03/2023 10:46, Eli Zaretskii wrote:
>>>> Cc:wkirschbaum <at> gmail.com,gregory <at> heytings.org,casouri <at> gmail.com,
>>>> 62333 <at> debbugs.gnu.org
>>>> Date: Fri, 31 Mar 2023 09:19:35 +0300
>>>> From: Eli Zaretskii<eliz <at> gnu.org>
>>>>
>>>>> 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?
>>>> No.
>>>>
>>>>> Or should the buffer contents after the string's closer now be
>>>>> highlighted as being inside a string?
>>>> Yes.
>>> To clarify: these my answers are in the context of the current
>>> handling of narrowing, not in the context of restricting the parser
>>> (which you seem to reject as a useful idea anyway).
>>
>> Interesting.
>>
>> You do realize that it doesn't work this way currently, right?
>
> Yes.
So... do you think we should flip font-lock-dont-widen's default to t?
Then the behavior can be like you answered, and we could alter other
features (e.g. indentation) too.
Note that that variable goes back to 2002, though.
And regarding indentation: with that kind of the change, narrowing
region to a fragment of a function definition (cutting out its
beginning) will usually make indentation shallower, when code outside of
narrowing is considered absent.
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.