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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

>>> 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  ;-)  ]

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

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

> 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`)


        Stefan