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

From: Dmitry Gutov <[email-masked]>
Date: Wed, 29 Mar 2023 00:19:41 +0300

On 28/03/2023 14:38, Eli Zaretskii wrote:
>> Date: Tue, 28 Mar 2023 02:33:38 +0300
>> Cc: [email-masked], [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>>> With parser-based features, we have an opportunity to do this in a
>>> cleaner manner.
>>
>> parser-based features don't need this at all, if considered in
>> isolation. But if we try to combine them with existing mode, or existing
>> packages, they need to play by the common rules. Which they currently do.
> 
> Sorry, I don't see the relevance of that to what I wrote above.
> 
>>>> If we take indent-for-tab-command, for example, it doesn't have such a
>>>> variable, and doesn't really need to: the top-level command calls
>>>> 'widen', and then indent-line-function (set by major mode and altered by
>>>> e.g. mmm-mode) is free to impose its specific bounds.
>>>
>>> I thought about a lower-level, infrastructure-level, mechanism that
>>> could be used to restrict a parser to a certain region of the buffer.
>>> Then this could be used by every feature based on parsers, instead of
>>> us having to invent a separate solution for each one.
>>
>> Like narrowing, but just for parsers? But parsers obey narrowing
>> already. Sounds a bit like conceptual duplication. How does this solve
>> blink-matching-paren issue anyway?
> 
> We could widen without fearing that a parser will "invade" regions of
> buffer text that we don't want it to wander into.

So any code that wants to restrict a "parser" based buffer, would need 
to use a different primitive to narrow? And vice versa, any code that 
uses a parser, will need to (widen) first, to ensure that the parser is 
not affected by any restriction set up by any code previously?

Anyway, I don't see why we should institute a special category for these 
buffers. Most language modes which define syntax-propertize-function are 
basically "parser-based", in most of the relevant respects. Except the 
accuracy is less, and we write the parsing code ourselves.

>>>> The "grand unified theory of mixed major modes" has been attempted a few
>>>> times in the past, and never reached anything practical.
>>>
>>> But here we have a unique opportunity to maybe find a solution, at
>>> least for stuff based on tree-sitter and similar libraries.  That
>>> maybe not "grand", but certainly "respectable".
>>
>> tree-sitter has its own support for mixed languages.
> 
> So your argument about mmm framework was a red herring, cause that
> problem doesn't exist wrt tree-sitter parsers?

Nope, see the first paragraph of my previous reply (the "no relevance" one).

>>>> My stance here is we shouldn't break it before we create a new one.
>>>
>>> No one broke anything.  We are just discussing ideas.  Please don't
>>> exaggerate.
>>
>> I never said anybody has broken anything already.
> 
> You did say that my ideas break something, see above.  Ideas cannot
> break any code, so this argument shouldn't be brought up if you want a
> calm and rational discussion.

Ideas cannot, but implementing them can. "This or that change will break 
an existing convention" is a rational argument.

Shall we stop quibbling over words?