bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Josh
Subject: bug#15478: cc-mode does not obey electric-indent-mode
Date: Mon, 7 Oct 2013 14:23:20 -0700

On Mon, Oct 7, 2013 at 6:11 AM, Alan Mackenzie <acm@muc.de> wrote:
> On Sun, Oct 06, 2013 at 10:45:59AM -0700, Josh wrote:
> > My previous question was based on a supposition (perhaps naive, as I'm
> > not at all familiar with the CC Mode code) that its indentation
> > functionality was either already centralized into a some "indent this
> > line properly" function or that it would be desirable and feasible to
> > make it so.  If that were so, it seemed to me that such a function
> > could be pressed into service as an electric-indent-function without
> > too much trouble.
> That could indeed be done, but the "too much trouble" would arise from
> having to maintain separate versions of this code for the current Emacs,
> and for Xemacs and historical Emacsen.
>
> Have a look at the code for `c-electric-brace' in cc-cmds.el.

OK, I did.  I saw what I take to be the embodiment of years of hard-won
experience about how to implement this functionality correctly, and I
fully agree that we could ill-afford to lose it.  In hindsight I don't
think I described the "centralized" `c-indent-this-line-properly'
function I have in mind very well so let me try again, continuing with
your example of braces.

Start by factoring the indentation logic out of the current
`c-electric-brace' implementation and call the extracted function
`c-electric-brace-indent'.  Call what's left `c-electric-brace*' and
change its behavior to merely insert the brace and then call
`c-indent-this-line-properly' with the inserted character as an
argument.  The latter function would then dispatch to the appropriate
CC Mode indentation function, in this case the extracted
`c-electric-brace-indent'.  Here are the key bindings and call trees I
had in mind:

|--------+---------------------------------+--------------------------------|
|        | Current Emacs                   | XEmacs, older GNU Emacs        |
|--------+---------------------------------+--------------------------------|
| {,} -> | self-insert-command             | c-electric-brace*              |
|--------+---------------------------------+--------------------------------|
| Call   | electric-indent-post-self-[...] | c-electric-brace*              |
| Tree   | `- c-indent-this-line-properly  | `- c-indent-this-line-properly |
|        |    `- c-electric-brace-indent   |    `- c-electric-brace-indent  |
|--------+---------------------------------+--------------------------------|

In both cases, the same events (character insertion) trigger the same
CC Mode indentation code extracted from the current implementation.
I'm aware that such a scheme may be impractical for reasons unknown to
me, but otherwise then at least for indentation triggered by character
insertion the only maintenance burden I can see is that of the thin
c-electric-brace* wrapper.

> >   (or c-force-electric-flag electric-layout-mode electric-indent-mode)
> That's not going to gain anything, since `c-force-electric-flag' would
> need to default to t to preserve existing behaviour.

The need to preserve existing behavior is not a given.  The above
change would cause the (initial) enablement of electric behavior in CC
Mode to be predicated on global electricity enablement, which is the
subject of this bug.

> > .... Even so, it would be a vast improvement for newbies who do not
> > want this behavior.
>
> Yes, but it would be undesirable for those other newbies who do want
> automatic indentation.  "Newby" here means those unfamiliar with
> `c-toggle-electric-state' and `electric-indent-mode'.

Identifying the right set of defaults is important and likely to be an
extensive discussion in itself, but one that should take place as part of
some other bug.  This bug is about the fact that CC Mode disregards
configuration that is documented to be global.





reply via email to

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