|
From: | Dmitry Gutov |
Subject: | bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes |
Date: | Wed, 29 Mar 2023 00:19:41 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 |
On 28/03/2023 14:38, Eli Zaretskii wrote:
Date: Tue, 28 Mar 2023 02:33:38 +0300 Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org From: Dmitry Gutov <dgutov@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?
[Prev in Thread] | Current Thread | [Next in Thread] |