[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: Fri, 22 Jan 2021 20:33:37 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Many (almost all?) modes bind RET to newline-and-indent,
> Any mode which does that should be fixed.

Ouch... I see now that my "observation" was plain wrong.  CPerl mode
does it, but only as a user preference.  When I checked other modes with
C-h k, I did it in an Emacs instance where I had it globally remapped.
I failed to check the sources.  Sorry for the confusion.

> Whether RET indents or not is a user preference, not something that
> should depend on the kind of language you're editing.

For most programming and markup languages indenting makes sense, but
less so for other modes.  I understand that python-mode disables it, but
was a bit surprised that c-mode disables it, too (I understand it now
after following two lengthy threads on debbugs).

I guess it wouldn't hurt to add a sentence to the docstring of
electric-indent-mode how it should be managed for a single buffer.  The
method with an extra variable (electric-indent-inhibit, works only to
disable a globally enabled mode) or an extra mode
(electric-indent-local-mode, works both ways) is somewhat nonstandard
and the question seems to pop up occasionally on various platforms.

>> So, whenever a newline is entered,
> By that I assume you simply mean whenever `newline-and-indent` is executed?

Yes.  I thought that I meant "whenever I hit the enter key" but this was
only true because I had mapped it that way.

>> there are three calls to the mode-specific indenting function:
>>  - one call for the current line, caused by electric-indent-mode.  [...]
>>  - two calls for the following, empty line.  One is caused by '(?\n)
>>    being in electric-indent-chars, the other by the current command
>>    being newline-AND-INDENT.  This doesn't make any sense.
> It sounds like a bug indeed.  I think both having two calls (one for
> each line) or having one call (for the new line) could arguably be
> correct, but three calls is indeed an error.

So... I guess newline-and-indent could suppress the call to
indent-line-function for the new line if electric-indent-mode is t and
electric-indent-inhibit is nil and ?\n is in electric-indent-chars?

Just for the record: The results are correct, and the delay isn't
noticeable even with the convoluted indenting routines of CPerl mode.
It is just a bit annoying when you are tracing through the routines
trying to figure out where to fix a bug.

>> Or should the modes refrain from mapping RET?
> Very much so, yes (unless there's a good language-related reason why RET
> should behave differently for that specific language).

I now see that they actually don't do this.  Sorry again.

In CPerl mode, the remaining issue is actually the other way around.
You can activate cperl-electric-linefeed via customize to do
newline-and-indent.  However, when you don't set this option, you still
get newline ... and indent, thanks to electric-indent-mode.

So, that customization option is futile since whenever 2013-ish
electric-indent-mode became default.  I take the total lack of customer
protests and bug reports as a hint that Perl programmers actually are
quite fine with indenting as they type.

reply via email to

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