From: Dmitry Gutov <dgutov@yandex.ru>
To: Alan Mackenzie <acm@muc.de>
Cc: "João Távora" <joaotavora@gmail.com>,
"Yuan Fu" <casouri@gmail.com>, "Eli Zaretskii" <eliz@gnu.org>,
"theodor thornhill" <theo@thornhill.no>,
geza.herman@gmail.com, "Daniel Colascione" <dancol@dancol.org>,
emacs-devel@gnu.org
Subject: Re: treesit indentation "blinking"
Date: Mon, 3 Apr 2023 15:07:11 +0300 [thread overview]
Message-ID: <6efb9f84-211d-560e-3196-95d7f0b8be19@yandex.ru> (raw)
In-Reply-To: <ZCqjjPSbnl8eGTxb@ACM>
On 03/04/2023 12:59, Alan Mackenzie wrote:
> Hello, Dmitry.
>
> On Mon, Apr 03, 2023 at 00:21:18 +0300, Dmitry Gutov wrote:
>> On 02/04/2023 20:23, João Távora wrote:
>>> So my initial idea was to tone down electric-indent-chars, at least
>>> for the moment. And Dmitry's idea was to make electric-indent-chars
>>> be ambitious_only_ if electric-pair-mode is enabled (by the user).
>>> Maybe we should bring back that idea, and it seems the least bad of the
>>> bunch right now.
>
>> Alternatively, we only perform "electric indent" (aside from after RET)
>> when the parse tree does not contain errors.
>
> That is NOT electric indentation. The whole point about electric
> indentation is for it to take effect whilst point is still on the line
> being edited. Thus, for example, you can see whether or not the line
> needs breaking, or whether there's room for a short comment at the end
> of the line.
Wouldn't you know whether the line needs breaking, as long as the line
was indented correctly when you opened it with RET?
> What you're proposing is something which would almost never trigger,
> since a line being edited will not have a parse tree without errors (if
> I've understood that properly). If it did trigger at some point, that
> would likely cause annoyance and puzzlement.
That's a fair assessment, but it's going to trigger in a lot of cases
still: after ;, or after a paren or brace being closed.
This is not a substitute for enabling electric-pair-mode, alas. Just a
less hackish way to check the same thing rather than check for this
particular mode being enabled.
I would also prefer c++-ts-mode supported indentation with closing
braces missing, but we're really limited by what the parser provides.
E.g. for this code
int foo() {
for (;;) {
we get this parse tree:
(ERROR (primitive_type)
(function_declarator declarator: (identifier)
parameters: (parameter_list ( )))
{ for ( ; ; ) {)
where the "for" statement isn't even present (the separate tokens are
parsed as leaf nodes, and that's it). It's difficult to write meaningful
indentation rules that would match this.
next prev parent reply other threads:[~2023-04-03 12:07 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
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 [this message]
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=6efb9f84-211d-560e-3196-95d7f0b8be19@yandex.ru \
--to=dgutov@yandex.ru \
--cc=acm@muc.de \
--cc=casouri@gmail.com \
--cc=dancol@dancol.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=geza.herman@gmail.com \
--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).