Re: treesit indentation "blinking"

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 2772 bytes --]



On March 23, 2023 16:04:16 Yuan Fu <casouri@gmail.com> wrote:

>> On Mar 22, 2023, at 9:51 PM, Daniel Colascione <dancol@dancol.org> wrote:
>>
>> On March 22, 2023 21:03:29 Yuan Fu <casouri@gmail.com> wrote:
>>
>>>> On Mar 22, 2023, at 5:07 PM, Daniel Colascione <dancol@dancol.org> wrote:
>>>>
>>>>
>>>>
>>>> On March 22, 2023 20:00:23 Yuan Fu <casouri@gmail.com> wrote:
>>>>
>>>>>> On Mar 22, 2023, at 1:49 PM, Daniel Colascione <dancol@dancol.org> wrote:
>>>>>>
>>>>>> Is there a general-purpose through which we can avoid line indentation
>>>>>> oscillating as the user types when the AST is temporarily invalid,
>>>>>> e.g. after '(' or '{'? I'm checking out the C++ tree-sitter mode, and
>>>>>> one of the more disconcerting things is the current line's indentation
>>>>>> changing rapidly as I type. Is it feasible to create ERROR recovery
>>>>>> indentation rules for every conceivable situation?
>>>>>
>>>>> Yes, but in reality, I think all we need is a couple special case for the 
>>>>> unmatched ( and {’s. Can you think of other cases of blinking indentations?
>>>>>
>>>>> Yuan
>>>>
>>>> But TS reacts to missing closing brackets by clarifying the whole nearby 
>>>> expression as ERROR. It's not, as would be more useful, saying "here's a 
>>>> stray (, and everything else is normal and parsed as if that ( were absent”
>>>
>>> We can just look at the buffer text directly: if there’s an ERROR and the 
>>> previous char (after skipping whitespace chars) is ( or {, we know what to do
>>
>>
>> Do we know what to do? That ERROR might be arbitrarily far up the parse 
>> tree. I don't think it's as easy as you think it might be. One strategy 
>> that might work is to see whether adding a "(" introduced an error, and, if 
>> so, temporarily replacing that "(" with whitespace, reparsing, and then 
>> using the resulting parse tree instead of the one with the "(" to do 
>> indentation and fontification. This way, I think you'd end up without the 
>> random jumping around we see today in TS modes.
>
> We can place this special rule at the end of our rule list, and previous 
> rules not matching should indicated “error” by itself. Of course, I can’t 
> prove it by using this method to fix the blinking indent, but I don’t quite 
> have the time for it right now.


Editing can cause all sorts of transient nonsense in the AST, and it's 
impossible to predict in a general manner what this nonsense might be. The 
wrong kind of bracket can cause the entire rest of the file to be parsed as 
nonsense. This or that error recovery rule isn't going to solve the 
problem: such a strategy is a fragile whack a mole. There needs to be some 
general solution to prevent indentation blinking. This blinking makes TS 
modules unusable for me.


[-- Attachment #2: Type: text/html, Size: 4673 bytes --]