unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: dgutov@yandex.ru,  dancol@dancol.org,  casouri@gmail.com,
	emacs-devel@gnu.org,  theo@thornhill.no
Subject: Re: treesit indentation "blinking"
Date: Thu, 30 Mar 2023 10:06:19 +0100	[thread overview]
Message-ID: <87y1newqus.fsf@gmail.com> (raw)
In-Reply-To: <83mt3u65vw.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 30 Mar 2023 10:43:47 +0300")

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Date: Wed, 29 Mar 2023 22:30:29 +0000
>> Cc: dgutov@yandex.ru, dancol@dancol.org, casouri@gmail.com, 
>> 	emacs-devel@gnu.org, theo@thornhill.no
>> 
>> > > diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
>> > > index 59eb9fc23e6..88360716381 100644
>> > > --- a/lisp/progmodes/c-ts-mode.el
>> > > +++ b/lisp/progmodes/c-ts-mode.el
>> > > @@ -956,10 +956,6 @@ c-ts-base-mode
>> > >    ;; Comment
>> > >    (c-ts-common-comment-setup)
>> > >
>> > > -  ;; Electric
>> > > -  (setq-local electric-indent-chars
>> > > -              (append "{}():;,#" electric-indent-chars))
>> > > -
>> > >    ;; Imenu.
>> > >    (setq-local treesit-simple-imenu-settings
>> > >                (let ((pred #'c-ts-mode--defun-valid-p))
>> > >
>> > > In master?  In emacs-29?
>> >
>> > I suggest to do this in emacs-29, but conditionally, with a
>> > defcustom.  This will allow users to try both ways and maybe we will
>> > have some feedback regarding what is the best way.
>> 
>> I'm not fond of creating a defcustom to work around what I consider
>> as a simple bug and to configure something which the user can already
>> configure with a two-line mode hook addition.
>
> I think this conclusion is at least inaccurate, if not incorrect.
> IOW, this is not "a simple bug", it could be an issue with different
> personal preferences or something else.  See below for details.
>
>> So I won't do that change myself.
>
> That's a strange stance.  Discussion of solutions to issues can
> legitimately conclude that some solution could be subject to personal
> preferences, some of which you don't share.  Refusing to install a
> change you yourself suggested with such minor adjustments, just
> because it doesn't fit your personal preferences in editing C/C++
> code, sounds at least unfriendly.

Oh dear.  "at least unfriendly"?

Eli, I'm just trying to help. I don't use c++-ts-mode yet.  It's still
very immature IMO.  Someone in this thread mentioned electric-pair-mode,
a mode I authored, and its (positive) effects on bouncing indentation.

Apparently noone had looked into electric-indent-chars for the cause, or
provide a recipe.  I did and proposed a trivial solution for anreal
problem that I wasn't the first or even the second to witness.

If you don't like my patch, it's fine.  Use the results of my
experiments as you see fit.  But just don't want to figure out a
defcustom name, a default value, etc and contribute to an Emacs with
more defcustoms for areas where I personally believe defcustom aren't
the answer.  I won't stop anyone from adding one.  Is this "unfriendly"?
Geez.

>> And then my personal opinion is that it is an annoying
>> feature to have on by default as it whole lines about.
>> Having electric-indent-chars set to '(?\n), like c++-mode
>> has, is fine.
>
> Let's back up a notch and revisit the evidence, okay?
>
> First, I don't agree with your conclusion that the local setting of
> electric-indent-chars in c-ts-base-mode causes divergent behavior wrt
> its CC mode equivalents.  In particular, the example you brought up in
>
>   https://lists.gnu.org/archive/html/emacs-devel/2023-03/msg00939.html
>
> behaves the same in c++-mode, at least in "emacs -Q": "std:" (with a
> single colon) causes reindentation as if this were a label, and adding
> another colon indents back to column 2.  So at least in this example
> the behavior I see is the same in both modes.

I didn't realize that, because I use c++-mode with its electric features
off.  But I've already given a different MRE for bounciness.

I think within 5 minutes of editing, someone used to c++-mode -- even
with its default electricity -- will start to feel unconfortable with
c++-ts-mode.  I saw bouncing in lots of other places, bouncing that I
know I just don't see with c++-mode.  If I ever pick it up again, I'll
let the ts people know.

I also see "Mismatched parenthesis" warnings where none exist, there's
and MRE for that also below.

> Also, at least some of the examples for a different behavior between
> c++-mode and c++-ts-mode explicitly turned OFF electric-indent-mode.
> For example, see
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62412#14
>
> When electric-indent-mode is turned OFF, setting electric-indent-chars
> cannot possibly make any difference, right?
>
> (Btw, I cannot reproduce what the first example there says: if I turn
> OFF electric-indent-mode, RET doesn't correctly indent the next line;
> instead, the next line is not indented at all.  So I wonder what is
> being missed here.)

What's being missed is that perhaps you're mixing electric-pair-mode
with electric-indent-mode? In these tests I never turned off e-i-m,
because it's on by default in Emacs.  In these tests I do turn e-p-m on
and off to investigate claims by other users that it helps and measure
by how much.

> More generally, the claim that CC mode doesn't alter
> electric-indent-chars doesn't really explain the differences in
> behavior, because while the claim is factually true, CC mode gives
> some characters electric behavior that is independent of
> electric-indent-chars, see the node "Electric Keys" in the CC Mode
> manual.  What happens here is that keys like '#', '*', '<', '(', '{',
> ':', and others are bound to CC mode specific commands like
> c-electric-pound and c-electric-brace, which reindent the code if
> electric-indent-mode is turned on in the buffer.

Sure, I've already said that I missed this electricity.  I turn off
c++-mode electricity, and so that example was flawed.  I'm deeply, truly
sorry.  But I've already provided a better example.

> Bottom line: I think both this thread and the discussion in bug#62412
> have a lot of misunderstandings and examples at least I cannot
> reproduce, 

Maybe because of the mix-up between e-p-m and e-i-m mentioned above?

I already gave this alternative MRE of bouncing behaviour.

   emacs -Q `mktemp`.cpp -f c++-ts-mode  

   i n t SPC m a i n ( ) { RET for ( ; ; ) SPC b l a ( ) ;  

Can you reproduce this bouncing?  Now try the same with c++-mode. Do you
confirm that it doesn't bounce?  Also in c++-ts-mode, add a closing `}`.
See the "mismatched parenthesis"?

Now I'm going to give another example.  In the same file, go back to
c++-ts-mode.  Say you spotted a mistake and dont want an infloop after
all.  Go and delete the two ';;' in the for expressions, leaving, say
just the parenthesis.  Start typing another set of expressions.  See the
bouncing back and forth?  I've even made a gif of this.


[-- Attachment #2: bouncing.gif --]
[-- Type: image/gif, Size: 70095 bytes --]

[-- Attachment #3: Type: text/plain, Size: 9 bytes --]


João

  parent reply	other threads:[~2023-03-30  9:06 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 [this message]
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
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=87y1newqus.fsf@gmail.com \
    --to=joaotavora@gmail.com \
    --cc=casouri@gmail.com \
    --cc=dancol@dancol.org \
    --cc=dgutov@yandex.ru \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --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).