From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: 15478@debbugs.gnu.org
Subject: bug#15478: cc-mode does not obey electric-indent-mode
Date: Wed, 02 Oct 2013 21:50:06 -0400 [thread overview]
Message-ID: <jwvtxgzjlbv.fsf-monnier+emacsbugs@gnu.org> (raw)
In-Reply-To: <20131002200737.GA3895@acm.acm> (Alan Mackenzie's message of "Wed, 2 Oct 2013 20:07:37 +0000")
> Without electricity, correct indentation would require continual pressing
> of the <tab> key.
Yes. Just as is the case in all major modes.
> "|" 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.
>> Most major modes don't enable electric-layout by default (and AFAICT
>> most users care more about "indent after newline", which cc-mode
>> doesn't enable anyway).
> "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 ;-).
> Are you saying that, in CC Mode, users would prefer electric
> indentation on the C-j rather than the semicolon, etc.?
No. I'm saying that if they like electric indentation on {, }, and ;,
then they probably also like it on RET. And in my experience, beginning
users ask a lot more about "how do I get Emacs to put point at the right
place after RET" than after any other key.
> 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.
> 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.
>> 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?
> 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.
> 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.
> 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), but most modes should
just obey the default setting which reflects the user's preference.
> 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.
> 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.
Stefan
next prev parent reply other threads:[~2013-10-03 1:50 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-28 18:10 bug#15478: cc-mode does not obey electric-indent-mode Stefan Monnier
2013-09-28 20:11 ` Alan Mackenzie
2013-09-29 3:02 ` Stefan Monnier
2013-09-29 9:10 ` Alan Mackenzie
2013-09-30 18:23 ` Stefan Monnier
2013-10-02 20:07 ` Alan Mackenzie
2013-10-03 1:50 ` Stefan Monnier [this message]
2013-10-03 2:46 ` Daniel Colascione
2013-10-03 4:10 ` Stefan Monnier
2013-10-03 4:13 ` Daniel Colascione
2013-10-03 4:50 ` Stefan Monnier
2013-10-03 5:56 ` Andreas Röhler
2013-10-03 6:31 ` Daniel Colascione
2013-10-03 15:52 ` Eli Zaretskii
2013-10-03 13:15 ` Dmitry Gutov
2013-10-03 15:04 ` Stefan Monnier
2013-10-03 17:40 ` Andreas Röhler
2013-10-03 9:45 ` Alan Mackenzie
2013-10-03 14:02 ` Stefan Monnier
2013-10-03 17:45 ` Andreas Röhler
2013-10-03 10:56 ` Alan Mackenzie
2013-10-03 14:32 ` Stefan Monnier
2013-10-04 21:21 ` Josh
2013-10-05 16:50 ` Alan Mackenzie
2013-10-06 17:45 ` Josh
2013-10-07 13:11 ` Alan Mackenzie
2013-10-07 21:23 ` Josh
2013-10-09 17:55 ` Alan Mackenzie
2013-10-03 11:54 ` Alan Mackenzie
2013-10-03 17:43 ` Andreas Röhler
2013-10-05 17:06 ` Alan Mackenzie
2013-10-06 1:10 ` Stefan Monnier
2013-10-06 2:55 ` Eli Zaretskii
2013-10-06 5:04 ` Josh
2013-10-07 9:39 ` Alan Mackenzie
[not found] ` <20131007093859.GA3859@acm.acm>
2013-10-07 16:05 ` Eli Zaretskii
2013-10-07 21:17 ` Josh
2013-10-08 6:49 ` Eli Zaretskii
2013-10-08 15:59 ` Josh
2013-10-09 17:32 ` Alan Mackenzie
[not found] ` <20131009173206.GA2610@acm.acm>
2013-10-10 19:11 ` Josh
2013-10-06 17:01 ` Stefan Monnier
2013-10-12 14:54 ` bug#15596: Let's improve the default workings of electric-indent-mode Alan Mackenzie
2013-10-12 16:35 ` Stefan Monnier
2013-10-13 12:36 ` Alan Mackenzie
2013-10-14 2:16 ` Stefan Monnier
2013-10-07 10:30 ` bug#15478: cc-mode does not obey electric-indent-mode Alan Mackenzie
[not found] ` <20131007103041.GB3859@acm.acm>
2013-10-07 16:14 ` Stefan Monnier
2013-10-07 20:37 ` Alan Mackenzie
[not found] ` <20131007203738.GA3099@acm.acm>
2013-10-07 23:08 ` Stefan Monnier
2013-10-05 17:08 ` Alan Mackenzie
2014-02-17 19:02 ` Alan Mackenzie
[not found] ` <20140217190249.GB4173@acm.acm>
2014-02-18 0:04 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvtxgzjlbv.fsf-monnier+emacsbugs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=15478@debbugs.gnu.org \
--cc=acm@muc.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.