From: haj@posteo.de (Harald Jörg)
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Emacs Developer List <emacs-devel@gnu.org>
Subject: Re: newline-and-indent vs. electric-indent-mode
Date: Sat, 23 Jan 2021 17:27:42 +0100 [thread overview]
Message-ID: <87a6szy5xd.fsf@hajtower> (raw)
In-Reply-To: <jwv4kj8s5nq.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri, 22 Jan 2021 22:29:06 -0500")
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> 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 ...
I've already done that. It was part of my ancient customization stuff I
wasn't aware of any more. I guess that was all that needed to be done
to fix my doubts.
>> 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.
Agreed, I also consider this very valuable.
> 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.
Well... actually, as a user, I don't want to be bothered with such
choices while I'm typing. I want to hit RET and have the mode figure
out what needs to be done so that the code follows some coding
convention. But that's only me, so "anecdotal evidence".
This choice might be of interest for mode maintainers, though. They
might want to check how new user settings or global minor modes affect
their mode's behavior. Maybe mode authors should wrap
‘electric-indent-local-mode’ with a mode-specific command (in
particular: a mode-specific docstring) because users shouldn't be
supposed to figure out this particular's mode's settings for
‘electric-indent-functions’ and ‘electric-indent-chars’, which is all
they get from the docstring of the global ‘electric-indent-mode’
command.
> It also brings back the behavior they had before `electric-indent-mode`.
I'm sure this is correct. I wasn't aware of it since I only used Emacs
sporadically in that era.
>> 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".
I should rephrase that: They should according to my user expectation
(basically Damian Conway's book Perl Best Practices, or perltidy
conventions) - regardless of whether the current implementation of
`cperl-linefeed` is up to this task.
> Hell! I don't even know half of what the "fancystuff" does, so maybe
> I'm just plain wrong about what should be done.
CPerl mode is full of fancy stuff :) In particular, it can rewrite
(not just indent) existing code to make it conforming to styleguides.
Or just to "beautify" it.
That said, I don't use this often, and maybe it isn't that popular
overall. My main interest isn't the fancy stuff. I want to, however,
support features which have been added to Perl in the current century.
Therefore I struggle to understand how CPerl mode does things, and how
it probably should do things in contemporary Emacs.
So, bottom line: I've understood a lot about the intention of
electric-indent-mode, about the current implementation and about my own
blunders. Thanks for your patience!
--
Cheers,
haj
prev parent reply other threads:[~2021-01-23 16:27 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
2021-01-23 16:27 ` Harald Jörg [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a6szy5xd.fsf@hajtower \
--to=haj@posteo.de \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.