[Top][All Lists]

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

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

From: Dmitry Gutov
Subject: Re: newline-and-indent vs. electric-indent-mode
Date: Sun, 24 Jan 2021 04:54:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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

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.


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.

reply via email to

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