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

From: Alan Mackenzie <[email-masked]>
Date: Mon, 7 Oct 2013 13:11:22 +0000

Hi, Josh.

On Sun, Oct 06, 2013 at 10:45:59AM -0700, Josh wrote:
> On Sat, Oct 5, 2013 at 9:50 AM, Alan Mackenzie <[email-masked]> wrote:
> > On Fri, Oct 04, 2013 at 02:21:22PM -0700, Josh wrote:
> > > On Thu, Oct 3, 2013 at 7:32 AM, Stefan Monnier <[email-masked]

> If CC Mode performs indentation only after character insertion,
> why couldn't it continue to do its own electric indentation entirely
> after being actuated by this hook, returning `no-indent' to ensure it
> had complete control?

This is more or less what I have in mind.

> If CC Mode reindentation is additionally or only triggered by events
> other than character insertion, what are those events?  Timers?
> Hooks?  This is what I was getting at when I asked how the existing
> delegation mechanisms fall short.

CC Mode reindentation is done only at character insertion; each electric
character key is bound to a function, e.g. c-electric-brace, which
performs its own electric actions.

> > > Is there a reason why CC Mode couldn't supply a function here that
> > > would perform appropriate indentation and then return `no-indent' to
> > > stop traversal of electric-indent-functions?

> > It would be a lot of work to rearrange things, and it might leave the
> > Emacs 24.4 version incompatible with other CC Mode versions.

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

> > > Although I agree with your earlier point that major modes are best
> > > suited to make decisions about /how/ to perform electric behavior for
> > > their specific domains, which also seems to be borne out by the existing
> > > delegation support, I've seen no justification for a major mode deciding
> > > to disregard (!) my configuration of /whether/ to perform it at all.

> > Currently, that configuration is done by setting `c-electric-flag',
> > either in your .emacs or by C-c C-l.  `electric-indent-mode' is the new
> > kid on the block.  Concrete suggestions for integrating `c-electric-flag'
> > and `electric-indent-mode' haven't been copious up till now.  I've one or
> > two ideas myself, but it's not trivial.

> Indeed, it would have been better for this discussion to have taken
> place concurrently with the introduction of a piece of global
> configuration specifying default behavior at odds with that of
> existing mode-granular configuration, but that's water under the
> bridge.

Indeed so.  I accept my share of the blame for this not being done.

> As for their integration, I have already confessed to being unfamiliar
> with CC Mode code, but perhaps until a better long-term solution has
> been specified and implemented a reasonable stopgap measure would be to
> set the default value of c-electric-flag to

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

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

> > Perhaps there need to be three values here, 'default, t and nil.

> Perhaps so, but until that time I expect my global configuration
> settings to be observed regardless of whether they remain at the
> default values or whether the developers of some mode or library
> I'm using think those defaults are sensible.

Other people expect their default settings (of `c-electric-flag') to be
observed, too.  Those defaults clash.  This problem is getting resolved.

-- 
Alan Mackenzie (Nuremberg, Germany).