bug#15478: cc-mode does not obey electric-indent-mode

[Alan Mackenzie]

Hi, Stefan.

On Wed, Oct 02, 2013 at 09:50:06PM -0400, Stefan Monnier wrote:
> > Without electricity, correct indentation would require continual pressing
> > of the <tab> key.

> Yes.  Just as is the case in all major modes.

No.  Electric indentation is completely unneeded in Emacs Lisp Mode,
because the indentation of each line is dependent only on previous lines,
not the content of the line itself.

> > "|" indicates the position of point.  Now type "{".  With electricity,
> > the "{" is instantly indented to its correct position under the "if".
> > Without electricity, the user needs to remember to type <tab> before C-j
> > on L4.  This is an unacceptable default state, IMAO.

> That's because *you* like electric-indent-mode.  Not because C is special.

No, it's not just my preference.  All modes should indent correctly
automatically, by default.  Electricity is essential to CC Mode's
achieving this.

> > "Indent after newline" seems redundant in CC Mode;

> Redundancy is not a problem, AFAIK.  In my case, for example, CC-mode's
> electric indentation on {, }, and semi-colon is redundant, because I hit
> TAB anyway without even thinking about it (and C-x C-s very soon after
> that ;-).

But you need to hit <tab> _after_ typing the brace, but _before_ typing
C-j.  This doesn't seem like an effective way of working.  Do you really
run C Mode without electric indentation?

> > Such a change could involve extensive work

> Could be.  And maybe not only in CC-mode but also in electric.el.

> > the electric behaviour is coded individually in defuns like
> > `c-electric-brace' and includes more electric behaviour than just
> > indentation - for example, auto-newlining.

> `electric-layout-mode' provides similar functionality, IIUC.

OK.  I didn't know about `electric-layout-mode'.

> > As an exercise, yes.  But disregarding existing behaviour should not be
> > done frivolously; CC Mode's electric behaviour has been remarkably
> > stable, with (as far as I am aware) only one complaint about it (not
> > counting the current one) in at least 12 years (see below).

> There's been several request to "turn off indentation" over the years
> (usually answered with something like "set c-syntactic-indentation")
> which would not have occurred without those electric keys: it's easy to
> rebind TAB or avoid hitting TAB, but if after that "random other keys"
> keep insisting on indenting for you, it gets very frustrating.

Setting c-syntactic-indentation to nil was an unsatisfactory workaround.
The problem was solved (with c-electric-flag and C-c C-l) around 2005.

> >> For me, I'd like cc-mode to do as little as possible besides adding
> >> ?\;, ?\{, and ?\} to electric-indent-chars.
> > These characters should not trigger electric indentation when typed
> > inside a string or a comment.  electric-indent-mode isn't best placed to
> > make such distinctions.

> Why not?

Because each such distinction is going to be major mode specific.  CC
Mode additionally suppresses electric indentation when a repeat count is
given before typing the character.

> > It doesn't seem to be the Right Thing to split the electric activity
> > between electric-indent-mode (for indentation) and c-electric-brace
> > and friends (for auto-newlining and clean-ups).

> As explained, there's electric-layout-mode for auto-newlining.  Not sure
> what "clean-ups" is about, but we can probably work something out.

Clean-ups, for example, remove auto-newlines when it later transpires
they're unwanted.  For example, one clean-up converts

    }
    else
    {

to

    } else {

on typing the "{".

> > I think electric-indent-mode, as it currently is, is capable of
> > improvement.  It is a single flag, but really needs to be major-mode
> > dependent; it fouls up Python indentation (unless that's been recently
> > fixed) and I think I recall reading that it messed up something in
> > Outline Mode; yet CC Mode needs electricity.  electric-indent-mode needs
> > to be buffer local.

> I'm all for improving electric-indent-mode.  And indeed, it needs
> improvement for indentation-sensitive modes like Python and Haskell.

Does it even make sense for these modes?

> > Each major mode needs its own default for e-i-m:

> I disagree with it: some major modes need their own default because
> their syntax has something very special, e.g. incompatible with
> electric-indent-mode (Python/Coffescript/Haskell), ...

Does that even make sense?  How can Python have its own default, yet C
not?

> ... but most modes should just obey the default setting which reflects
> the user's preference.

The default setting doesn't reflect a user's preference, if that
preference is ON for C, OFF for Python, and the major mode specific
optimum for everything else.

> > something like `electric-indent-mode-alist', analogous with
> > `auto-mode-alist'.  This default would be consulted at mode
> > initialisation time.

> I don't see why the major mode can't just set a var in its major-mode
> function for the rare cases where it can be needed, and why the user
> can't make his own choice via the major-mode's hook, if needed.

Because, as so often in this list, we're talking about defaults, not the
extent to which an experienced user can customise his Emacs.  Defaults
are important.

> > A buffer's setting of e-i-m should also be more than just nil or t.  That
> > is inflexible to an un-Emacs like degree.  At the very least, there
> > should be some sort of setting that means "electric indentation is
> > performed entirely by the major mode".

> I don't understand what you're suggesting.

You seem to be suggesting dismantling not only CC Mode's electric
indentation, but its auto-newlining too.  The generic replacements for
them are going to be less good.  What I'm suggesting is some sort of hook
so that electric-indent-mode (and electric-layout-mode, too, I suppose)
invokes the "electric engine" in CC Mode rather than trying to do the
electric indentation itself.

Dismantling electricity in CC Mode and replacing it by generic
functionality would be a massive amount of work for no functional gain.
It would break advanced users' setups and cause maintenance pain, due to
incompatibility with the CC Mode standalone version and the XEmacs
version.  Let's not go down that road.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).