bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes

[Dmitry Gutov <dgutov@yandex.ru>]

On 31/03/2023 16:03, Eli Zaretskii wrote:
>> Date: Fri, 31 Mar 2023 15:38:33 +0300
>> Cc: wkirschbaum@gmail.com, gregory@heytings.org, casouri@gmail.com,
>>   62333@debbugs.gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>>
>> On 31/03/2023 10:46, Eli Zaretskii wrote:
>>>> Cc:wkirschbaum@gmail.com,gregory@heytings.org,casouri@gmail.com,
>>>>    62333@debbugs.gnu.org
>>>> Date: Fri, 31 Mar 2023 09:19:35 +0300
>>>> From: Eli Zaretskii<eliz@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.