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: Alan Mackenzie
Subject: bug#15478: cc-mode does not obey electric-indent-mode
Date: Sat, 5 Oct 2013 16:50:34 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hi, Josh.

On Fri, Oct 04, 2013 at 02:21:22PM -0700, Josh wrote:
> On Thu, Oct 3, 2013 at 7:32 AM, Stefan Monnier <address@hidden>
> wrote:
> > > 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.
> > Sounds OK.

> Unless I'm misunderstanding, the indentation hook you're describing
> seems very close to `electric-indent-functions':

I'd say it's moderately close rather than very close.  At the moment CC
Mode does its own electric indentation entirely, and I'd like things to
stay that way, so as to minimise incompatibility between versions, to
avoid breaking existing users' setups and so on.

>     electric-indent-functions is a variable defined in `electric.el'.
>     Its value is nil
>       This variable may be risky if used as a file-local variable.
>     Documentation:
>     Special hook run to decide whether to auto-indent.
>     Each function is called with one argument (the inserted char), with
>     point right after that char, and it should return t to cause
> indentation,
>     `no-indent' to prevent indentation or nil to let other functions decide.

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

> Delegation of newline insertion decisions is similarly already supported
> via `electric-layout-rules':

>     electric-layout-rules
>     electric-layout-rules is a variable defined in `electric.el'.
>     Its value is nil
>     Documentation:
>     List of rules saying where to automatically insert newlines.
>     Each rule has the form (CHAR . WHERE) where CHAR is the char
>     that was just inserted and WHERE specifies where to insert newlines
>     and can be: nil, `before', `after', `around', or a function of no
>     arguments that returns one of those symbols.

> If either or both of these delegation mechanisms are insufficient to
> satisfy CC Mode's requirements, it would be interesting to hear how they
> fall short.

CC Mode already does electric actions by other means, and users setups
depend on these.  I don't want to break these existing setups.
Integrating CC Mode's ways with these new mechanisms is a challenge.

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

> I read the electric-*-mode docstrings describing the exact behavior in
> question and I disabled it.  That should be the end of the story.

Yes.  But there's a difference between you disabling it and merely using
the default value.  Since the current default is already nil, it's not
clear what you mean by "disabling" it.  Perhaps there need to be three
values here, 'default, t and nil.  It's also still up for discussion how
you {en,dis}able electric-indent-mode buffer locally, which is a sensible
thing to want to do.

> Josh

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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