[Top][All Lists]

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

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

From: Stefan Monnier
Subject: bug#15478: cc-mode does not obey electric-indent-mode
Date: Mon, 07 Oct 2013 12:14:19 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

>> Emacs has never provided this feature in any mode that I know, cc-mode
>> included.  Some major modes (such as CC-mode) try to provide some vague
>> approximation of it, using "electric keys" that trigger indentation
>> "often enough" that it works more or less OK in some common cases.
> :-).  I think CC Mode DTRT practically 100% of the time.  There haven't
> been bug reports asking for the details of the electric indentation to be
> improved.

I can assure you it doesn't work 100%: in many circumstances you have to
hit TAB (or M-C-\ or M-C-q) manually before the text's indentation
reflects the modifications that took place.

I don't think it's a failure of your code, tho (and
electric-indent-mode fails in the exact same way).

> from 1992.  Somebody (RMS?  Barry Warsaw?) clearly thought it very
> important.

I thought it's important enough to embark on electric-indent-mode
(which is reasonably easy to implement, except it's hellish to get all
the various authors to get back in line and start using the generic
infrastructure, for the long term benefit of end users, at the cost
of short term disruption and extra work).

>> No they're not.  And I think it's blatantly obvious, even to you.
>> I understand that simply to mean that you do not want CC-mode's default
>> behavior to change.
> You're not wrong there.

Thank you.

>> The core is then: how should we make cc-mode integrate better with Emacs
>> and use the generic electric-*-mode functionality instead of
>> rolling its own?
> How about aliasing `c-electric-mode' and `electric-indent-mode' and
> making them buffer-local in CC Mode buffers?  Then setting CC Mode's
> value of `electric-indent-chars' to nil, for now, and in the medium
> future (once e-i-m has percolated through to old versions and XEmacs)
> integrating CC Mode into electric-indent-mode properly?

Poor, but does satisfy the requirements.

> How about introducing `global-electric-indent-mode' and redefining e-i-m
> to be buffer-local?  Or, alternatively, leaving e-i-m as it is and
> defining `local-electric-indent-mode'?

`electric-indent-local-mode' sounds good.

> What about defining a property `no-electric-indentation' which could
> be set on python-mode and others?

I wouldn't use a property.  Just a buffer-local variable
`electric-indent-inhibit' which those modes can set.
For Python and Haskell, this should only inhibit *re*indentation, while
still calling indent-according-to-mode after inserting a newline.

>> For the record: CC-mode is not the only major mode in this boat.
>> I've already converted several major modes to use electric-indent-mode,
>> and for some of them this also involved changing the default behavior.
> Would you identify (some of) these modes, please, so I can go and have a
> look.

If you "grep electric-indent- **/*.el" you'll find some of them (I also
changed a few external ones like sml-mode).

Note that in most cases I made the change by completely side-stepping
the old code (i.e. the define-key that rebinds the keys to electric
versions was either removed or made conditional on something like
(fboundp 'electric-indent-mode)).

And those were usually simpler than what cc-mode does, with the
exception maybe of octave.el where the old behavior was a bit more
complex, and replaced by a mix of electric-indent-mode,

But in most of those cases, I only made a minimal effort at trying to
preserve old behavior and user's customization.  I've seen a few
questions about "why foo-mode doesn't indent as before", and the answer
"it's now controlled by electric-indent-mode" always seemed to satisfy
the user.


reply via email to

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