Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Dmitry Gutov]

Alan Mackenzie <address@hidden> writes:

>> > A mode-dependent or buffer-local dependent setting, as well as, rather
>> > than instead of.
>
>> We have that: electric-indent-local-mode and electric-indent-inhibit.
>
> OK, for electric-indent-local-mode, which is gradually becoming
> prominent.  But I though electric-indent-inhibit was a variable for major
> modes, not users - a mode initialisation thing, rather than a user
> configuration variable.

This is usually the case with buffer-local dependent settings. They're
impossible to set via Customize (I think), so one doesn't usually think
of them as user options, but a user can modify such var in a hook, too.

>  b - Simplify `electric-indent-post-self-insert-function' such that it
>    reindents only the line on which the self-inserting character is
>    typed.

It would still need to handle presence of ?\n in `electric-indent-chars'
when that's the case.  This value is somewhat special since the
line-to-be reindented would be the previous, not the current one.

> 2. For making RET indent the new line in programming modes:
>   a - Bind RET to `newline-and-indent' and C-j to `newline' in
>     `prog-mode-map' and possibly in certain other major mode maps (to be
>     discussed).

I believe there's something to be said for consistency: having RET
indent line in some modes, but not others doesn't make much sense to me.

There's a certain class of users who've been binding RET to
`newline-and-indent' for a long time (myself included), and I haven't
seen anyone mention only doing that in prog-mode, instead of globally.

>   b - (Maybe) create a minor mode to restore RET and C-j to traditional
>     bindings.

How hard can it be for a user to change the key bindings without a mode?

>> So make this bug report specific about a particular circumstance where
>> the behavior is undesirable, or about how hard it is to disable it.
>
> I think RMS's bug #16156, reproduced and being discussed on a parallel
> thread, is a good enough example, so there's not much point in me opening
> a new one.

This behavior, as described in the bug above, makes sense to me, so it's
clearly a personal preference.