unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: "João Távora" <joaotavora@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	dancol@dancol.org, casouri@gmail.com, emacs-devel@gnu.org,
	theo@thornhill.no
Subject: Re: treesit indentation "blinking"
Date: Thu, 30 Mar 2023 19:29:44 +0300	[thread overview]
Message-ID: <f2b4a9f9-f91b-a26e-69be-16b1ff735ae2@yandex.ru> (raw)
In-Reply-To: <CALDnm53DK_0==Bt7-QH4srNgzT9TjU3wseMMVOUjief2LyWZxg@mail.gmail.com>

On 30/03/2023 13:00, João Távora wrote:
> On Thu, Mar 30, 2023 at 10:36 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
>>
>> On 30/03/2023 12:28, João Távora wrote:
>>> This problematic already counts as "bouncing" to me, for some meaning of
>>> "bouncing". c++-mode doesn't behave like that because indentation is
>>> already where it is supposed to be if you type that sequence of
>>> keystrokes.
>>
>> Okay, if that's what you meant.
>>
>> I think this one (indentation after RET in an incomplete function
>> definition) should be fixed in the indentation rules. The contents of
>> electric-indent-chars won't fix it either way.
> 
> This is all down to indentation rules, that's how electric-indent-mode
> decides what to do.  My point is that having electric-indent-chars be
> this ambitious with "broken" indentation rules isn't a good place to
> be.

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.

> 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).

> 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.



  reply	other threads:[~2023-03-30 16:29 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-22 20:49 treesit indentation "blinking" Daniel Colascione
2023-03-23  0:00 ` Yuan Fu
2023-03-23  0:07   ` Daniel Colascione
2023-03-23  1:02     ` Yuan Fu
2023-03-23  4:51       ` Daniel Colascione
2023-03-23 20:04         ` Yuan Fu
2023-03-23 21:10           ` Daniel Colascione
2023-03-23 21:24             ` Dmitry Gutov
2023-03-25  9:05               ` João Távora
2023-03-25 12:42                 ` Dmitry Gutov
2023-03-25 14:42                   ` Eli Zaretskii
2023-03-25 16:18                     ` João Távora
2023-03-28 22:11                       ` João Távora
2023-03-28 23:57                         ` Daniel Colascione
2023-03-29  2:26                         ` Eli Zaretskii
2023-03-29 22:30                           ` João Távora
2023-03-29 22:37                             ` Herman, Géza
2023-03-29 23:25                               ` João Távora
2023-03-30  7:47                                 ` Herman, Géza
2023-03-29 22:56                             ` Lynn Winebarger
2023-03-30  7:43                             ` Eli Zaretskii
2023-03-30  8:58                               ` Dmitry Gutov
2023-03-30  9:15                                 ` João Távora
2023-03-30  9:06                               ` João Távora
2023-03-30  9:20                                 ` Dmitry Gutov
2023-03-30  9:28                                   ` João Távora
2023-03-30  9:36                                     ` Dmitry Gutov
2023-03-30 10:00                                       ` João Távora
2023-03-30 16:29                                         ` Dmitry Gutov [this message]
2023-03-30 17:14                                           ` João Távora
2023-03-30 10:07                                 ` Eli Zaretskii
2023-03-30 10:26                                   ` Herman, Géza
2023-03-30 13:39                                     ` Eli Zaretskii
2023-03-30 15:03                                       ` Herman, Géza
2023-03-30 14:58                                     ` Eli Zaretskii
2023-04-01 19:39                                       ` Yuan Fu
2023-04-02  1:49                                         ` Yuan Fu
2023-04-02  5:31                                           ` Eli Zaretskii
2023-04-02 14:26                                           ` Alan Mackenzie
2023-04-02 15:48                                             ` João Távora
2023-04-02 17:04                                               ` Alan Mackenzie
2023-04-02 17:23                                                 ` João Távora
2023-04-02 17:51                                                   ` Eli Zaretskii
2023-04-02 18:04                                                     ` João Távora
2023-04-02 18:14                                                       ` Eli Zaretskii
2023-04-02 21:38                                                         ` João Távora
2023-04-02 21:21                                                   ` Dmitry Gutov
2023-04-02 21:40                                                     ` João Távora
2023-04-03  9:59                                                     ` Alan Mackenzie
2023-04-03 10:28                                                       ` João Távora
2023-04-03 12:07                                                       ` Dmitry Gutov
2023-04-03 12:56                                                         ` Alan Mackenzie
2023-04-03 20:58                                                           ` Dmitry Gutov
2023-04-03 21:59                                                         ` Daniel Colascione
2023-04-03 22:10                                                           ` Dmitry Gutov
2023-04-04  8:31                                                           ` João Távora
2023-04-07 14:20                                                           ` Daniel Martín
2023-04-08  1:32                                                             ` Dmitry Gutov
2023-04-08  2:42                                                               ` Yuan Fu
2023-04-08 18:59                                                               ` Daniel Martín
2023-04-03 21:47                                             ` parser error recovery algorithm vs " Stephen Leake
2023-04-04 12:01                                               ` John Yates
2023-04-04 13:40                                                 ` Dmitry Gutov
2023-04-04 16:00                                                   ` Stephen Leake
2023-04-04 13:50                                                 ` Stephen Leake
2023-04-04 14:05                                                   ` Dmitry Gutov
2023-03-30 11:05                                   ` João Távora
2023-03-30 14:00                                     ` Eli Zaretskii
2023-03-30 14:43                                       ` João Távora
2023-03-30 14:52                                         ` Eli Zaretskii
2023-03-30 15:42                                           ` João Távora
2023-03-25 16:14                   ` João Távora
2023-03-24 11:39             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f2b4a9f9-f91b-a26e-69be-16b1ff735ae2@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=casouri@gmail.com \
    --cc=dancol@dancol.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@gmail.com \
    --cc=theo@thornhill.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).