Re: treesit indentation "blinking"

[João Távora]

On Thu, Mar 30, 2023 at 5:29 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> In this instance, removing chars off electric-indent-chars won't conceal
> the problem: the user can still type RET or press TAB and see unexpected
> indentation where Emacs should have been able to guess the correct one.

electric-indent-chars exacerbates an existing problem.

IOW, it's much easier to live with incorrect indentation for temporarily
invalid programs if it's not shuffling the ground under your feed as
you type, which I think is exactly what was reported here.

It's perfectly analogous with electric-pair-mode.  It only makes sense
to turn it on if the syntax code counting openers and closers is doing
its job.  Else it's just a nuisance.

So it only makes sense to have an ambitious
electric-indent-chars or even electric-indent-mode at all if the indentation
rules are solid and predictable.  Which they are to a certain extent in c+
+-mode and to much lesser extent in c++-ts-mode.

And even if c++-ts-mode's could be made easily predictable, making them
match c++-mode's exactly probably still another job.  One that I
personally wouldn't bother with.  I don't know if that's the goal.

> > What counts as "broken" indentation is also arguable though. When dealing
> > with invalid programs, there is really no "right" or "wrong" indentation.
> > See my message https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62412#14 where
> > I show cases where c++-ts-mode's answer to indenting an invalid program
> > makes more sense than c++-mode's answer.
>
> It's not cut-and-dried indeed, but historically, with the "native" major
> modes we, wittingly or not, have used the principle that code fully
> typed until point is considered "decidable", even if some missing code
> after point makes the it incomplete. Even though, on rare occasions,
> continuing to type might change the indentation again (e.g. for "case
> labels", if the indent style dedents them).

Yes, true.  But as Stefan once pointed out, that's just an arbitrary
decision.  Though I agree it's a fairly consistent one.  Probably because
I'm also used to it.  It could be the other way around and look backwards
leaning towards facilitating editing of code instead of typing new code.

> > Whatever the indentation rules, the current bouncing is so jarring
> > that it really doesn't encourage people to try switching to
> > c++-ts-mode, get used to its set of indentation rules, and then perhaps
> > experience its other benefits like, say, performance or simplicity.
> >
> > At least it didn't for me.  I'm back to c++-mode atm.
> >
> > In my opinion electric-indent-char should be reduced to the default
> > and should be added criteriously as the indentation rules they trigger
> > are fixed.
>
> We should probably revisit this after an honest attempt to fix these two
> cases.

Works for me.  My point is that I won't be using much c++-ts-mode in the
meantime. My guess is many users may be silently switching to it and
then back away to c++-mode in part due to this misbehaving electricity.
My point is that the mode should be more inviting to try out.

João