GNU bug report logs -
#62333
30.0.50; Issue with tree-sitter syntax tree during certain changes
Previous Next
Full log
Message #164 received at 62333 <at> debbugs.gnu.org (full text, mbox):
On 28/03/2023 14:38, Eli Zaretskii wrote:
>> Date: Tue, 28 Mar 2023 02:33:38 +0300
>> Cc: wkirschbaum <at> gmail.com, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>>> 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?
This bug report was last modified 2 years and 78 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.