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

[Dmitry Gutov <dgutov@yandex.ru>]

On 23.01.2021 05:16, Stefan Monnier wrote:
>> I'm not sure how it is a bug. It's "reindentation" in both cases, right?
>> And electric-indent-inhibit's docstring refers to reindentation.
> 
> But with the current behavior, a char other than \n into
> `electric-indent-chars` can never have any effect when
> `electric-indent-inhibit` is non-nil.  So I'd argue that a char other
> than \n should take precedence over `electric-indent-inhibit`,
> especially because such a char can only be there if it's been
> explicitly added.

All right, filed as bug#46064.

I suppose of a user wants to have those over vars not have effect, they 
can set those to nil in the major mode hook.

>>>> It's just that in my mental model \n doesn't belong to the current line,
>>>> only to the next one. So it shouldn't reindent the original line.
>>> It's often useful for me, as in typing
>>>       foo RET else RET blabla
>>> where the else benefits from being reindented upon the second RET.
>> I see. Well, ruby--electric-indent-p covers this scenario already.
> 
> Indeed, this approach can work as well.
> [ BTW, here's another one where ruby-mode is saved by the reindentation
>    done by `newline`: foo RET endl DEL RET  ;-)  ]

This one can be also solved by 'undo' instead of DEL, but yes.

>> Perhaps your approach is simpler, but always reindenting the original line
>> gets annoying if the indentation function sometimes produces suboptimal
>> results.
> 
> I think `electric-indent-mode` is annoying in any case if the
> indentation code disagrees with your style.

True, but my present complaint is about it being annoying *twice* for 
the same line. And if it's being annoying while point is still on that 
line, it's marginally easier to fix.

> There are lots of knobs to
> play with deciding when and were indentation happens, and it's hard to
> know what the statistically optimal heuristic.  So I won't try to argue
> that the current choice is best, but I think it's equally hard to argue
> that some other choice is best.

Agreed.

> If we could automatically detect when a reindentation is immediately
> undone by the user, maybe we could collect statistics.

That might help with indentation defaults (if the statistics is sent 
back to us somehow), but not with specific cases, I think. And the 
indentation code has to be capable of producing the needed indentation 
patterns, at least with some values of indentation-related options.

>> again, or undo the change and go with C-o C-n TAB.
> 
> I think `C-j TAB` is quicker (but I must admit that my muscle memory
> often makes me do `C-q C-j TAB`)

Oh, right.

In the meantime, I'll try running with RET bound to newline-and-indent, 
like in good old days.