[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: newline-and-indent vs. electric-indent-mode

From: Harald Jörg
Subject: Re: newline-and-indent vs. electric-indent-mode
Date: Sat, 23 Jan 2021 17:27:42 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

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’

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]