unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: haj@posteo.de (Harald Jörg)
Cc: Emacs Developer List <emacs-devel@gnu.org>
Subject: Re: newline-and-indent vs. electric-indent-mode
Date: Fri, 22 Jan 2021 22:29:06 -0500	[thread overview]
Message-ID: <jwv4kj8s5nq.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87a6t0z974.fsf@hajtower> ("Harald Jörg"'s message of "Sat, 23 Jan 2021 03:19:27 +0100")

>> Concrete examples would be helpful and could be reported as bugs ...
> I don't think these are bugs, but my personal user preference is to have
> RET indent in programming modes but not in text modes.

You might like to try removing that customization and then complain
about the cases that don't behave like you want.  I don't guarantee I'll
agree, but since `electric-indent-mode` is globally enabled by default,
I think it's important to try and make sure it's not too annoying in
those modes where it's not helpful.

>> I know it takes many people by surprise (because the choices are more
>> refined than just "on or off" and they don't expect that), but I find it
>> hard to improve the docs to guide the users/programmers.
> I admit that the whole electric-indent stuff is new to me.  I saw it
> happening but never checked *why* it is happening.  First time I noticed
> it explicitly was in the backtrace leading to my original post.

Yes, it happened because I think it's important to consolidate the
needs shared by all major modes.  It's surprisingly hard work, because
every major mode tends to do it slightly differently, so the
consolidated version is never "quite the same", thus encountering a lot
of resistance to change.

> Wouldn't that result in `newline` re-indenting both the new and the
> previous line (as per electric-indent-mode), but `newline-and-indent`
> *not* re-indenting the previous line?

Yes.

> That would seem a bit surprising.

Then again, the users have the choice of either calling
`newline-and-indent` or `reindent-then-newline-and-indent`, so
presumably when they choose `newline-and-indent` it's because they don't
want the first line to be reindented.

It also brings back the behavior they had before `electric-indent-mode`.

> First experiments suggest that the patch does indeed change the behavior
> when a line contains just a closing "]" or ")" - neither
> (newline-and-indent) nor (cperl-linefeed) now re-indent that line (which
> they should)

This behavior is the behavior that `cperl-linefeed` had when it was
written, so I disagree with "they should".

>> IMO keybindings is more harmful than anything here, so a better choice
>> would be to offer only plain newline and newline+indent+fancystuff, bind
>> them to RET and LFD, let `electric-indent-mode` control which of RET and
>> LFD does which, and let `cperl-electric-linefeed` control whether
>> fancystuff is done at all.
>
> That sounds good... it would need some unraveling to prevent deep
> recursion.  `electric-indent-mode` calls the mode-specific indentation
> function, which would optionally call fancystuff, which in turn calls
> both newline-and-indent _and_ the mode-specific indentation function.

I haven't even looked at what it would take in terms of coding.
Hell!  I don't even know half of what the "fancystuff" does, so maybe
I'm just plain wrong about what should be done.
In other words: I won't be touching this code any time soon (I'd much
rather add some of the "fancystuff" features to `perl-mode`, where
I wouldn't need to worry about breaking old cperl-mode users's habits).


        Stefan




  reply	other threads:[~2021-01-23  3:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22 13:53 newline-and-indent vs. electric-indent-mode Harald Jörg
2021-01-22 14:49 ` Stefan Monnier
2021-01-22 15:02   ` Dmitry Gutov
2021-01-22 15:09     ` Stefan Monnier
2021-01-22 22:43       ` Dmitry Gutov
2021-01-22 22:56         ` Stefan Monnier
2021-01-22 23:00           ` Dmitry Gutov
2021-01-22 23:16             ` Stefan Monnier
2021-01-23  0:45               ` Dmitry Gutov
2021-01-23  3:16                 ` Stefan Monnier
2021-01-24  2:54                   ` Dmitry Gutov
2021-01-24  5:29                     ` Stefan Monnier
2021-01-24 21:45                       ` Dmitry Gutov
2021-01-25  1:56                   ` Madhu
2021-01-25  2:29                     ` Dmitry Gutov
2021-01-25 10:45                       ` Madhu
2021-01-25 11:59                         ` Dmitry Gutov
2021-01-25 14:36                         ` Stefan Monnier
2021-01-25 14:42                           ` Dmitry Gutov
2021-01-25 15:15                             ` Stefan Monnier
2021-01-25 20:10                               ` Rudolf Schlatte
2021-01-26  2:04                               ` Dmitry Gutov
2021-01-26  2:43                                 ` Stefan Monnier
2021-01-26 15:58                               ` martin rudalics
2021-01-25  3:33                     ` Eli Zaretskii
2021-01-22 19:33   ` Harald Jörg
2021-01-22 22:05     ` Stefan Monnier
2021-01-23  2:19       ` Harald Jörg
2021-01-23  3:29         ` Stefan Monnier [this message]
2021-01-23 16:27           ` Harald Jörg

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=jwv4kj8s5nq.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=haj@posteo.de \
    /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).