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

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Tue, Mar 25, 2014 at 03:37:15AM +0200, Dmitry Gutov wrote:
> Alan Mackenzie <acm@muc.de> 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.

That's not what I meant.  I meant something more like
electric-indent-inhibit being a setting which defines a major mode rather
than being a way of configuring it.

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

Yes to all of that.  But I expressed myself precisely, and meant what I
wrote.

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

Indentation (in the sense of what `indent-line-function' does) only makes
sense in programming (etc.) modes.  In text modes, and the like,
indentation is, in practice, done with adaptive fill prefices.

Having RET do `newline-and-indent' in Emacs Lisp Mode while doing
`newline' in Text Mode makes a lot of sense to me.  A trickier question
is to identify which of the non-programming modes really want this sort
of indentation.

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

That was what we collectively decided last Autumn when the topic came up.

You've seen me mention it.  ;-)

Richard Stallman alluded to it in his disgust at bug #16156, when what
was bound to RET at the time zapped his indentation.

I personally would not be unhappy at leaving the traditional binding in
place for RET and C-j, but wouldn't mind them swapping in "indenting"
modes.  I'd object strongly to RET in text mode messing around with
indentation.

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

Middling, not very.  Such a minor mode might serve to damp down the
inevitable complaints the change in defaults will provoke.

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

By "makes sense" I think you mean "seems a sensible thing to do".  I take
issue with you here and say that, in Text Mode, it's a bizarre thing to
do.  I can't think of any normal circumstances where this behaviour would
be commonly desired; just how often in Text Mode do you not want RET just
to insert a new line when you type it at the beginning of a line?

-- 
Alan Mackenzie (Nuremberg, Germany).