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

[haj@posteo.de (Harald Jörg)]

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.
>
> Yes and now: historically, it's been quite common for major modes to do
> that kind of thing.  I've been fighting it for many years now (even
> long before `electric-indent-mode`) since it's usually the reflection of
> the major mode's author's preference, rather than something directly
> linked to the major mode ...

Guilty, Your Honour.

It would never occur to me to use any other than the RET key to advance
to the next line, plus DWIM (Do What I Mean).

I'm not the mode's author, though.

>>> 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.
>
> 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.  Org mode doesn't
indent, which is fine, but it has its own binding of RET (in a table it
does many fancy things, amongst them add a newline).

> `electric-indent-inhibit` doesn't inhibit auto-indentation.  It inhibits
> auto-*re*indentation.

Ah, thanks for the clarification.

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

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

> That would be one way, tho I find it fairly ugly.

Yeah, that has a certain smell. 

> Another might be to temporarily disable `electric-indent-mode`.  The
> more I think about it, the more I think this is the better choice.

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?  That would seem a bit surprising.

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) - only a plain RET does.

`newline-and-indent` could also temporarily enforce electric-indent-mode
with electric-indent-chars set to ?\n, let that minor mode do its job
while inserting the newline char, and never call indent-line-function by
itself.

>> [...]
> 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.
-- 
Cheers,
haj