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

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

[Stefan Monnier]

Package: Emacs
Version: 24.3.50


As the subject says, cc-mode should obey electric-indent-mode and only
perform auto-indent after inserting `;' or braces when the user has
requested it by enabling electric-indent-mode.


        Stefan




In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.20)
 of 2013-09-25 on pastel
Bzr revision: monnier@iro.umontreal.ca-20130924221059-tqcqd1227a84jehu
Windowing system distributor `The X.Org Foundation', version 11.0.11204000
System Description:	Debian GNU/Linux 7.1 (wheezy)

Configured using:
 `configure -C --enable-checking --enable-check-lisp-object-type
 'CFLAGS=-Wall -g3 -O1 -Wno-pointer-sign''

Important settings:
  value of $LANG: fr_CH.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: InactiveMinibuffer

Minor modes in effect:
  shell-dirtrack-mode: t
  electric-pair-mode: t
  electric-indent-mode: t
  url-handler-mode: t
  global-reveal-mode: t
  reveal-mode: t
  auto-insert-mode: t
  savehist-mode: t
  minibuffer-electric-default-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
C-x C-c <switch-frame> <switch-frame> <help-echo> <switch-frame> 
<switch-frame> <help-echo> C-x 1 . <down> <down-mouse-4> 
<mouse-4> <switch-frame> <switch-frame> <switch-frame> 
<left> <M-backspace> 3 <right> M-d o c t o b r e C-e 
<right> <up> <left> <right> <up> <left> <right> <down> 
<left> <right> <down> <left> <right> C-x C-s <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> C-l <down-mouse-4> 
<mouse-4> <double-down-mouse-4> <double-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<down-mouse-4> <mouse-4> <down-mouse-5> <mouse-5> <double-down-mouse-5> 
<double-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
C-s t p SPC # 1 C-a C-SPC <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> < ! - - SPC C-e C-a C-d 
< C-e <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<left> <left> - - > <return> C-x C-s <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <help-echo> 
<help-echo> <switch-frame> <switch-frame> <help-echo> 
<switch-frame> <switch-frame> <switch-frame> <help-echo> 
<help-echo> <help-echo> <switch-frame> n <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<help-echo> <down-mouse-1> <help-echo> <mouse-movement> 
<mouse-movement> <drag-mouse-1> <help-echo> <down-mouse-1> 
<mouse-1> <double-down-mouse-1> <double-mouse-1> <help-echo> 
<help-echo> C-x C-c M-: # x 1 b 0 0 0 0 <return> M-: 
M-p C-e <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> 1 0 0 0 0 <return> C-h v b 
l i n <tab> - m <tab> <tab> p <tab> <return> <switch-frame> 
<switch-frame> C-M-SPC M-w <help-echo> <help-echo> 
<down-mouse-1> <mouse-1> <double-down-mouse-1> <mouse-movement> 
<mouse-movement> <double-drag-mouse-1> <down-mouse-1> 
<mouse-1> <switch-frame> M-x r e p o - e m - b u g 
<tab> <return>

Recent messages:
Saving file /home/monnier/cours/ift-2035/A2013/index.html...
Wrote /home/monnier/cours/ift-2035/A2013/index.html
Mark saved where search started
Mark set
Saving file /home/monnier/cours/ift-2035/A2013/index.html...
Wrote /home/monnier/cours/ift-2035/A2013/index.html
1769472 (#o6600000, #x1b0000, ?ö°€€)
65536 (#o200000, #x10000, ?𐀀)
Making completion list...
Type "q" to delete help frame.

Load-path shadows:
/home/monnier/src/emacs/elpa/packages/company/.dir-locals hides /home/monnier/src/emacs/work/lisp/gnus/.dir-locals

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils org ob-tangle ob-ref
ob-lob ob-table org-footnote org-src ob-comint ob-keys org-pcomplete
org-list org-faces org-entities org-version ob-emacs-lisp ob org-compat
org-macs ob-eval org-loaddefs find-func midnight icalendar cal-x cal-tex
cal-html appt view cal-china lunar solar cal-dst cal-bahai cal-islam
cal-hebrew holidays hol-loaddefs warnings cal-french diary-lib
diary-loaddefs mule-util cal-move cal-menu calendar cal-loaddefs
misearch multi-isearch sgml-mode skeleton cus-edit cus-start cus-load
wid-edit autorevert filenotify doc-view jka-compr image-mode dired
format-spec executable copyright vc-bzr filecache reftex-dcr reftex
reftex-vars tex-mode compile shell pcomplete comint ansi-color ring
latexenc server noutline outline easy-mmode flyspell ispell eldoc
checkdoc thingatpt help-mode advice help-fns electric url-handlers
url-parse auth-source eieio byte-opt bytecomp byte-compile cconv
eieio-core gnus-util mm-util mail-prsvr password-cache url-vars reveal
autoinsert proof-site proof-autoloads cl-macs gv cl cl-loaddefs cl-lib
pg-vars uniquify time-date savehist minibuf-eldef disp-table finder-inf
info easymenu package bbdb-autoloads agda2 vm-autoloads tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

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

[Alan Mackenzie]

Hi, Stefan.

> Package: Emacs
> Version: 24.3.50


> As the subject says, cc-mode should obey electric-indent-mode and only
> perform auto-indent after inserting `;' or braces when the user has
> requested it by enabling electric-indent-mode.

There are problems with electric-indent-mode from the point of view of CC
Mode:

In particular, the electricity MUST be enabled by default in CC Mode,
otherwise automatic indentation won't work.  For example, after typing "}"
at the end of an otherwise blank line, the "}" typically needs to be
indented several spaces outwards.  electric-indent-mode appears to be
disabled by default.

electric-indent-mode is not buffer local; c-electric-flag is.

There is a key binding to toggle c-electric-flag, namely C-c C-l.

There is a set of "minor mode" toggling commands in CC Mode, and it would
seem not to be the Right Thing to destroy the coherence of this set.


>        Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

> In particular, the electricity MUST be enabled by default in CC Mode,
> otherwise automatic indentation won't work.  For example, after typing "}"
> at the end of an otherwise blank line, the "}" typically needs to be
> indented several spaces outwards.

I don't see in which way this is different for cc-mode than for any
other major mode.

> electric-indent-mode is not buffer local; c-electric-flag is.

Indeed, currently it can only be enabled globally.  But it can be
disabled per-buffer.
I haven't heard any complaint about it from users yet.

> There is a key binding to toggle c-electric-flag, namely C-c C-l.

I'm not sure that would prevent cc-mode from obeying electric-indent-mode.


        Stefan

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

[Alan Mackenzie]

'morning, Stefan.

On Sat, Sep 28, 2013 at 11:02:39PM -0400, Stefan Monnier wrote:
> > In particular, the electricity MUST be enabled by default in CC Mode,
> > otherwise automatic indentation won't work.  For example, after typing "}"
> > at the end of an otherwise blank line, the "}" typically needs to be
> > indented several spaces outwards.

> I don't see in which way this is different for cc-mode than for any
> other major mode.

I'm not familiar enough with these other modes to be able to say.  But
what exactly are you saying here?  Even if CC Mode is not different from
the other modes, that doesn't change the fact that electricity must be
enabled by default in CC Mode.

> > electric-indent-mode is not buffer local; c-electric-flag is.

> Indeed, currently it can only be enabled globally.  But it can be
> disabled per-buffer.
> I haven't heard any complaint about it from users yet.

> > There is a key binding to toggle c-electric-flag, namely C-c C-l.

> I'm not sure that would prevent cc-mode from obeying
> electric-indent-mode.

Perhaps not, but there is a good deal of thinking and scheming needed
before this can be done.  For CC Mode simply to `and' in the variable
electric-indent-mode when testing c-electric-flag would cause breakage,
confusion and bug reports.  Or perhaps should CC Mode set a buffer-local
copy of e-i-m to t at initialisation?  Should C-c C-l be extended also
to toggle e-i-m?  And so on....

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

> I'm not familiar enough with these other modes to be able to say.  But
> what exactly are you saying here?  Even if CC Mode is not different from
> the other modes, that doesn't change the fact that electricity must be
> enabled by default in CC Mode.

I don't see anything that requires electric-indent to be enabled by
default in cc-mode.  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).

So, yes, I do think that the default behavior of cc-mode should be changed.

> Perhaps not, but there is a good deal of thinking and scheming needed
> before this can be done.  For CC Mode simply to `and' in the variable
> electric-indent-mode when testing c-electric-flag would cause breakage,
> confusion and bug reports.  Or perhaps should CC Mode set a buffer-local
> copy of e-i-m to t at initialisation?  Should C-c C-l be extended also
> to toggle e-i-m?  And so on....

There are several separate issues, and they can be handled somewhat
separately.  First, let's see what we'd ultimately want to have as
behavior, disregarding backward compatibility and preservation of
previous behaviors.  For me, I'd like cc-mode to do as little as
possible besides adding ?\;, ?\{, and ?\} to electric-indent-chars.
I'm not convinced there's a real need for a key binding that toggles
electric-indent buffer-locally, but if there is, then I don't see why
cc-mode needs it more than any other mode.


        Stefan

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

[Alan Mackenzie]

Hi, Stefan.

On Mon, Sep 30, 2013 at 02:23:55PM -0400, Stefan Monnier wrote:
> > I'm not familiar enough with these other modes to be able to say.  But
> > what exactly are you saying here?  Even if CC Mode is not different from
> > the other modes, that doesn't change the fact that electricity must be
> > enabled by default in CC Mode.

> I don't see anything that requires electric-indent to be enabled by
> default in cc-mode.

Without electricity, correct indentation would require continual pressing
of the <tab> key.  E.g., in C Mode, k&r style (set with C-c .), enter the
following, pressing C-j at the end of each line:

1. int foo (bar)
2. {
3.      if (foo)
4.           |

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

> 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; the line will have
been electrically indented by the semicolon, brace, or comma typed just
before the C-j.  Are you saying that, in CC Mode, users would prefer
electric indentation on the C-j rather than the semicolon, etc.?  If so,
what evidence do you have for this?

> So, yes, I do think that the default behavior of cc-mode should be changed.

Such a change could involve extensive work - the electric behaviour is
coded individually in defuns like `c-electric-brace' and includes more
electric behaviour than just indentation - for example, auto-newlining.

> > Perhaps not, but there is a good deal of thinking and scheming needed
> > before this can be done.  For CC Mode simply to `and' in the variable
> > electric-indent-mode when testing c-electric-flag would cause breakage,
> > confusion and bug reports.  Or perhaps should CC Mode set a buffer-local
> > copy of e-i-m to t at initialisation?  Should C-c C-l be extended also
> > to toggle e-i-m?  And so on....

> There are several separate issues, and they can be handled somewhat
> separately.  First, let's see what we'd ultimately want to have as
> behavior, disregarding backward compatibility and preservation of
> previous behaviors.

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

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

> I'm not convinced there's a real need for a key binding that toggles
> electric-indent buffer-locally, but if there is, then I don't see why
> cc-mode needs it more than any other mode.

There was a complaint sometime at or before 2005 that CC Mode text was
"jumping all over the place", from a new Emacs user.  The solution, after
some discussion (in which you were involved) was to introduce
`c-electric-flag' with C-c C-l to toggle it.  That way, the newbie can
easily disable the electricity, yet equally easily experiment with
turning it on as soon as she feels she has got some control back again.
It is a handy toggle to have around when editing chaotically indented
code, or indeed small amounts of code indented differently from the
current style.

#########################################################################

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.

Each major mode needs its own default for e-i-m: something like
`electric-indent-mode-alist', analogous with `auto-mode-alist'.  This
default would be consulted at mode initialisation time.

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

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

> 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

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

On 10/2/13 6:50 PM, Stefan Monnier wrote:
>> 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.

Electric indentation is more useful in a language like C than it is in
something like Python --- C has a richer set of brace characters.
cc-mode's sophisticated syntactic indentation is an Emacs "killer feature".

Anyway, we should be showcasing it by default, using electric
indentation, instead of hiding it behind configuration because users
might want to lobotomize their indentation by rebinding <tab>.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Stefan Monnier]

>> That's because *you* like electric-indent-mode.  Not because C is special.
> Electric indentation is more useful in a language like C than it is in
> something like Python --- C has a richer set of brace characters.

Right: Python is indeed special because fully automatic indentation is
not really possible.  But C is not special in this respect.

> cc-mode's sophisticated syntactic indentation is an Emacs "killer feature".

The "sophisticated syntactic indentation" is also a killer feature for
Octave users, SML users, Lisp users, Javascript users, ...

> Anyway, we should be showcasing it by default, using electric
> indentation, instead of hiding it behind configuration because users
> might want to lobotomize their indentation by rebinding <tab>.

That's arguing for changing the global default of electric-indent-mode.

Whereas this bug report is about changing cc-mode to follow the
global preference, whichever way it's set.


        Stefan

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

On 10/2/13 9:10 PM, Stefan Monnier wrote:
> That's arguing for changing the global default of electric-indent-mode.
> 
> Whereas this bug report is about changing cc-mode to follow the
> global preference, whichever way it's set.

Sure. I agree that having cc-mode use the normal electric functionality
would be better overall. But making this transition without turning
electricity on by default would be making Emacs worse and would make
Emacs less attractive in the eyes of new users, who will evaluate the
editor's defaults, not its capabilities. If we do want to make cc-mode
use generic electricity facilities, we have to enable electricity by
default everywhere at the same time.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Stefan Monnier]

> Sure. I agree that having cc-mode use the normal electric functionality
> would be better overall.

Please make a separate bug report for it.  This one is about cc-mode.


        Stefan

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

[Andreas Röhler]

Am 03.10.2013 06:10, schrieb Stefan Monnier:
>>> That's because *you* like electric-indent-mode.  Not because C is special.
>> Electric indentation is more useful in a language like C than it is in
>> something like Python --- C has a richer set of brace characters.
>
> Right: Python is indeed special because fully automatic indentation is
> not really possible.  But C is not special in this respect.
>
>> cc-mode's sophisticated syntactic indentation is an Emacs "killer feature".
>
> The "sophisticated syntactic indentation" is also a killer feature for
> Octave users, SML users, Lisp users, Javascript users, ...
>
>> Anyway, we should be showcasing it by default, using electric
>> indentation, instead of hiding it behind configuration because users
>> might want to lobotomize their indentation by rebinding <tab>.
>
> That's arguing for changing the global default of electric-indent-mode.
>
> Whereas this bug report is about changing cc-mode to follow the
> global preference, whichever way it's set.
>
>
>          Stefan
>
>
>
>

Experience from python-mode says: better keep electric-stuff and common indent apart.

Being aware new users might be attracted by these shiny and useful features, for Emacs beginners
a lot of surprises may result.

IMHO that's part of the "steep learning curve", Emacs is often blamed of - too much electric stuff for beginners.

Rather tell at README and Info what to activate once it works.

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

On 10/2/13 10:56 PM, Andreas Röhler wrote:
> Experience from python-mode says: better keep electric-stuff and common
> indent apart.

What do you mean? I agree that the features should be separated in the
code and configured separately.

> Being aware new users might be attracted by these shiny and useful
> features, for Emacs beginners
> a lot of surprises may result.
> 
> IMHO that's part of the "steep learning curve", Emacs is often blamed of
> - too much electric stuff for beginners.

Python is special because the correct indentation, in the general case,
cannot be computed from buffer contents. As a result, electric
indentation will be frequently wrong and will annoy users. Electric
indentation in Python should default to off.

But most languages aren't like that. Most of the time, electric
indentation is a pure convenience, and should be on by default. I don't
agree that users would find it confusing in modes where indentation is
deterministic.

> Rather tell at README and Info what to activate once it works.

I couldn't disagree more strongly. Users don't read READMEs --- they
download a program, try it out, and in 15 minutes or so, decide whether
they want to invest time into it. Emacs needs to be better than other
editors out of the box. We can tell users how to turn _off_ electric
indentation in the documentation --- and we should probably add a menu
option for it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alan Mackenzie]

On Thu, Oct 03, 2013 at 12:10:16AM -0400, Stefan Monnier wrote:
> >> That's because *you* like electric-indent-mode.  Not because C is special.
> > Electric indentation is more useful in a language like C than it is in
> > something like Python --- C has a richer set of brace characters.

> Right: Python is indeed special because fully automatic indentation is
> not really possible.  But C is not special in this respect.

I.e., electric indentation needs to be off in Python.

> > cc-mode's sophisticated syntactic indentation is an Emacs "killer feature".

> The "sophisticated syntactic indentation" is also a killer feature for
> Octave users, SML users, Lisp users, Javascript users, ...

I.e., electric indentation needs to be on in C, Octave, .....

> > Anyway, we should be showcasing it by default, using electric
> > indentation, instead of hiding it behind configuration because users
> > might want to lobotomize their indentation by rebinding <tab>.

> That's arguing for changing the global default of electric-indent-mode.

The global default should be On for C and Off for Python.

> Whereas this bug report is about changing cc-mode to follow the
> global preference, whichever way it's set.

If it's been set.  New users, hacking in both C and Python, should be
able to have the major-mode dependent optimum, without having to set it.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hi, Stefan.

On Wed, Oct 02, 2013 at 09:50:06PM -0400, Stefan Monnier wrote:
> > Without electricity, correct indentation would require continual pressing
> > of the <tab> key.

> Yes.  Just as is the case in all major modes.

No.  Electric indentation is completely unneeded in Emacs Lisp Mode,
because the indentation of each line is dependent only on previous lines,
not the content of the line itself.

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

No, it's not just my preference.  All modes should indent correctly
automatically, by default.  Electricity is essential to CC Mode's
achieving this.

> > "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 ;-).

But you need to hit <tab> _after_ typing the brace, but _before_ typing
C-j.  This doesn't seem like an effective way of working.  Do you really
run C Mode without electric indentation?

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

OK.  I didn't know about `electric-layout-mode'.

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

Setting c-syntactic-indentation to nil was an unsatisfactory workaround.
The problem was solved (with c-electric-flag and C-c C-l) around 2005.

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

Because each such distinction is going to be major mode specific.  CC
Mode additionally suppresses electric indentation when a repeat count is
given before typing the character.

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

Clean-ups, for example, remove auto-newlines when it later transpires
they're unwanted.  For example, one clean-up converts

    }
    else
    {

to

    } else {

on typing the "{".

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

Does it even make sense for these modes?

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

Does that even make sense?  How can Python have its own default, yet C
not?

> ... but most modes should just obey the default setting which reflects
> the user's preference.

The default setting doesn't reflect a user's preference, if that
preference is ON for C, OFF for Python, and the major mode specific
optimum for everything else.

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

Because, as so often in this list, we're talking about defaults, not the
extent to which an experienced user can customise his Emacs.  Defaults
are important.

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

You seem to be suggesting dismantling not only CC Mode's electric
indentation, but its auto-newlining too.  The generic replacements for
them are going to be less good.  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.

Dismantling electricity in CC Mode and replacing it by generic
functionality would be a massive amount of work for no functional gain.
It would break advanced users' setups and cause maintenance pain, due to
incompatibility with the CC Mode standalone version and the XEmacs
version.  Let's not go down that road.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hi, Andreas.

Andreas R?hler <andreas.roehler@easy-emacs.de> wrote:
> Am 03.10.2013 06:10, schrieb Stefan Monnier:
>>>> That's because *you* like electric-indent-mode.  Not because C is special.
>>> Electric indentation is more useful in a language like C than it is in
>>> something like Python --- C has a richer set of brace characters.

>> Right: Python is indeed special because fully automatic indentation is
>> not really possible.  But C is not special in this respect.

>>> cc-mode's sophisticated syntactic indentation is an Emacs "killer feature".

>> The "sophisticated syntactic indentation" is also a killer feature for
>> Octave users, SML users, Lisp users, Javascript users, ...

>>> Anyway, we should be showcasing it by default, using electric
>>> indentation, instead of hiding it behind configuration because users
>>> might want to lobotomize their indentation by rebinding <tab>.

>> That's arguing for changing the global default of electric-indent-mode.

>> Whereas this bug report is about changing cc-mode to follow the
>> global preference, whichever way it's set.


>>          Stefan





> Experience from python-mode says: better keep electric-stuff and common indent apart.

That's the way it is in python-mode.  In CC Mode, automatic indentation
doesn't work without electricity.  A single global default for
electric-indent-mode is thus inadequate.

> Being aware new users might be attracted by these shiny and useful features, for Emacs beginners
> a lot of surprises may result.

> IMHO that's part of the "steep learning curve", Emacs is often blamed of - too much electric stuff for beginners.

> Rather tell at README and Info what to activate once it works.

I say, let the defaults reflect a properly functioning Emacs.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dmitry Gutov]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> Experience from python-mode says: better keep electric-stuff and common indent apart.
>
> Being aware new users might be attracted by these shiny and useful features, for Emacs beginners
> a lot of surprises may result.
>
> IMHO that's part of the "steep learning curve", Emacs is often blamed of - too much electric stuff for beginners.
>
> Rather tell at README and Info what to activate once it works.

I have no strong opinion about how cc-mode should work, but having to
search the documentation (or Internet) and manually enable features
users may take for granted in other editors is arguably a bigger part of
Emacs's "steep leaning curve".

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

[Stefan Monnier]

> The global default should be On for C and Off for Python.

There's a problem in your sentence: global means "for all modes",
whereas you only talk about C and Python.

My opinion is: default for python-mode should be off (I think we all agree
here) and default for cc-mode should be the same as the global default.

What the global default should be is another discussion.

>> Whereas this bug report is about changing cc-mode to follow the
>> global preference, whichever way it's set.
> If it's been set.

No: even if it's not been set by the user.


        Stefan

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

[Stefan Monnier]

>> > Without electricity, correct indentation would require continual pressing
>> > of the <tab> key.
>> Yes.  Just as is the case in all major modes.
> No.  Electric indentation is completely unneeded in Emacs Lisp Mode,

Nitpicking.

>> That's because *you* like electric-indent-mode.  Not because C is special.
> No, it's not just my preference.

That's what you say, but I don't see the evidence.  So far you've only
pointed to Elisp mode and Python mode as counter examples, but from
where I stand it's more like Elisp and Python are the exceptions (and
as soon as someone improves Elisp indentation for cl-lib constructs
or :keyword arguments, Elisp won't be an exception any more).

> All modes should indent correctly automatically, by default.

Again, you're arguing for enabling electric-indent-mode by default.
I'm not necessarily opposed to it, but it's a different issue than the
one I'm concerned with in this bug-report.

> But you need to hit <tab> _after_ typing the brace, but _before_ typing
> C-j.  This doesn't seem like an effective way of working.  Do you really
> run C Mode without electric indentation?

Of course.  And cc-mode is one of the very few modes where
electric-indent is so "in your face" all the time.

>> >> 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?
> Because each such distinction is going to be major mode specific.

That's not a good reason, since there's no technical difficulty in
making it possible for a major mode to tell electric-indent-mode which
behavior is desired.

>> > 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.
> Clean-ups, for example, remove auto-newlines when it later transpires
> they're unwanted.  For example, one clean-up converts
>     }
>     else
>     {
> to
>     } else {
> on typing the "{".

Ah, right.  I don't see any particular problem here, cc-mode can provide
a c-electric-cleanup-mode (or maybe we can even make it generic, so
other major modes can provide their own cleanup rules).

>> I'm all for improving electric-indent-mode.  And indeed, it needs
>> improvement for indentation-sensitive modes like Python and Haskell.
> Does it even make sense for these modes?

No, it doesn't, which is the needed improvement: make it default to Off
there even if it is enabled globally.

>> > 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), ...
> Does that even make sense?  How can Python have its own default, yet C
> not?

Technically, C could have its own default as well, of course.
I just don't see any reason for it.

> The default setting doesn't reflect a user's preference, if that
> preference is ON for C, OFF for Python, and the major mode specific
> optimum for everything else.

Indeed, which is why only very few major modes should override the
global default.  Python has a good reason to override it.  C doesn't.

>> > 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.
> Because, as so often in this list, we're talking about defaults, not the
> extent to which an experienced user can customise his Emacs.  Defaults
> are important.

My point above was arguing against using an electric-indent-mode-alist
mechanism rather than one of the standard mechanisms (setq-local for the
major-mode or add-hook for the user).  It was not about what the default
should be.

>> > 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.
> You seem to be suggesting dismantling not only CC Mode's electric
> indentation, but its auto-newlining too.  The generic replacements for
> them are going to be less good.

I don't want them to be less good.  They may be marginally less good, or
slightly different in some corner cases, of course.  But "significantly
less good" would be a bug to fix by improving the generic code.

As already mentioned, fixing this bug report may require fixes not just
in cc-mode but also in electric.el.

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


        Stefan

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

[Stefan Monnier]

Please, let's keep this bug-report's focus: making cc-mode obey
electric-indent-mode.  Discussion of default setting of
electric-indent-mode belongs elsewhere.


        Stefan

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

[Eli Zaretskii]

> Date: Wed, 02 Oct 2013 23:31:26 -0700
> From: Daniel Colascione <dancol@dancol.org>
> Cc: 15478@debbugs.gnu.org
> 
> We can tell users how to turn _off_ electric indentation in the
> documentation --- and we should probably add a menu option for it.

We already do have a menu option for it, at least for C: click
"C->Toggle" and see there.  (Although "Options" sounds much better to
me than "Toggle".)

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

[Andreas Röhler]

Am 03.10.2013 15:15, schrieb Dmitry Gutov:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>> Experience from python-mode says: better keep electric-stuff and common indent apart.
>>
>> Being aware new users might be attracted by these shiny and useful features, for Emacs beginners
>> a lot of surprises may result.
>>
>> IMHO that's part of the "steep learning curve", Emacs is often blamed of - too much electric stuff for beginners.
>>
>> Rather tell at README and Info what to activate once it works.
>
> I have no strong opinion about how cc-mode should work, but having to
> search the documentation (or Internet) and manually enable features
> users may take for granted in other editors is arguably a bigger part of
> Emacs's "steep leaning curve".
>

There is some point, okay.

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

[Andreas Röhler]

Am 03.10.2013 13:54, schrieb Alan Mackenzie:

>
> I say, let the defaults reflect a properly functioning Emacs.
>

Definitely yours,

Andreas

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

[Andreas Röhler]

Am 03.10.2013 11:45, schrieb Alan Mackenzie:
> On Thu, Oct 03, 2013 at 12:10:16AM -0400, Stefan Monnier wrote:
>>>> That's because *you* like electric-indent-mode.  Not because C is special.
>>> Electric indentation is more useful in a language like C than it is in
>>> something like Python --- C has a richer set of brace characters.
>
>> Right: Python is indeed special because fully automatic indentation is
>> not really possible.  But C is not special in this respect.
>
> I.e., electric indentation needs to be off in Python.
>
>>> cc-mode's sophisticated syntactic indentation is an Emacs "killer feature".
>
>> The "sophisticated syntactic indentation" is also a killer feature for
>> Octave users, SML users, Lisp users, Javascript users, ...
>
> I.e., electric indentation needs to be on in C, Octave, .....
>
>>> Anyway, we should be showcasing it by default, using electric
>>> indentation, instead of hiding it behind configuration because users
>>> might want to lobotomize their indentation by rebinding <tab>.
>
>> That's arguing for changing the global default of electric-indent-mode.
>
> The global default should be On for C and Off for Python.
>

Agreed, learned this for now, thanks all,

Andreas

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

[Josh]

[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]

On Thu, Oct 3, 2013 at 7:32 AM, Stefan Monnier <monnier@iro.umontreal.ca>
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':

    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?

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.

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

Josh

[-- Attachment #2: Type: text/html, Size: 2657 bytes --]

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

[Alan Mackenzie]

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 <monnier@iro.umontreal.ca>
> 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).

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

[Alan Mackenzie]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> The global default should be On for C and Off for Python.

> There's a problem in your sentence: global means "for all modes",
> whereas you only talk about C and Python.

:-).  Then please consider that last sentence of mine modified by
removing "global" from it.

> My opinion is: default for python-mode should be off (I think we all agree
> here) and default for cc-mode should be the same as the global default.

Yes, we agree about python-mode.  The default for CC Mode must be on,
otherwise automatic indentation is broken.

> What the global default should be is another discussion.

In the sense we now agree upon, there shouldn't be a global default,
just as there isn't a global default for `font-lock-keywords'.

>>> Whereas this bug report is about changing cc-mode to follow the
>>> global preference, whichever way it's set.

>> If it's been set.

> No: even if it's not been set by the user.

If it's not been explicitly disabled by the user, electric indentation
must be on in CC Mode.  Otherwise automatic indentation doesn't work.

>        Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Please, let's keep this bug-report's focus: making cc-mode obey
> electric-indent-mode.  Discussion of default setting of
> electric-indent-mode belongs elsewhere.

These two things are inextricably entangled.

>        Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

> The default for CC Mode must be on, otherwise automatic indentation
> is broken.

IIUC your notion of "automatic indentation" is that the text is kept
indented without the user hitting TAB, just as a side-effect of editing
the text.

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.

But while CC-mode has been doing that for "ever", it's not nearly as
important as you claim, as demonstrated by all the other major modes
that don't even try to do that.  *You* like this feature, and indeed
you're not alone.  But it has nothing to do with the language being
edited (other than the fact that the language doesn't make it completely
impossible, as is the case in Python).

For people who don't like electric-indent-mode, CC-mode's
c-electric-flag sucks just as much.

> > Please, let's keep this bug-report's focus: making cc-mode obey
> > electric-indent-mode.  Discussion of default setting of
> > electric-indent-mode belongs elsewhere.
> These two things are inextricably entangled.

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.

So, for the sake of it, from here on, let's please continue this
discussion under the premise that electric-indent-mode will be enabled
by default.

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.

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.
I delayed touching at cc-mode mostly because I know you're
very opinionated ;-)


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 05 Oct 2013 21:10:01 -0400
> Cc: gnu-emacs-bug@moderators.isc.org
> 
> But while CC-mode has been doing that for "ever", it's not nearly as
> important as you claim, as demonstrated by all the other major modes
> that don't even try to do that.  *You* like this feature, and indeed
> you're not alone.

Indeed, he is not: I also happen to like it, "forever".

> For people who don't like electric-indent-mode, CC-mode's
> c-electric-flag sucks just as much.

Who are they, except for you?  Why don't we hear any complaints about
that, except from you?

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

[Josh]

[-- Attachment #1: Type: text/plain, Size: 2923 bytes --]

On Sat, Oct 5, 2013 at 7:55 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Date: Sat, 05 Oct 2013 21:10:01 -0400
> > Cc: gnu-emacs-bug@moderators.isc.org
> > For people who don't like electric-indent-mode, CC-mode's
> > c-electric-flag sucks just as much.
> Who are they, except for you?  Why don't we hear any complaints about
> that, except from you?

    c-electric-flag is a variable defined in `cc-engine.el'.
    Its value is t

      Automatically becomes buffer-local when set.

    Documentation:
    Not documented as a variable.

Do you hear many complaints about other undocumented variables?

    C-c C-l runs the command c-toggle-electric-state, which is an
    interactive compiled Lisp function in `cc-cmds.el'.

    It is bound to C-c C-l, <menu-bar> <C> <Toggle...> <Electric mode>.

    (c-toggle-electric-state &optional ARG)

    Toggle the electric indentation feature.
    Optional numeric ARG, if supplied, turns on electric indentation when
    positive, turns it off when negative, and just toggles it when zero or
    left out.

This is the command that Alan has claimed solved the problem back in
2005 and makes it easy for newbies to easily disable electricity.  I
don't believe that is so.  Neglecting the fact that newbies are
unlikely to be familiar with Emacs' "electric" term of art and thus
unlikely to even make the connection between "c-toggle-electric-state"
and the behavior they're trying to disable, this docstring makes no
mention whatsoever of `c-electric-flag', nor does it describe how to
disable electric behavior permanently.  (One might reasonably assume
that the global setting would govern here, but as we know it does
not.)  Perhaps the newbie would have enough Lisp to make the leap from
that docstring to adding
  (c-toggle-electric-state -1)
to her init file, but since that function is not autoloaded it would
likely only result in a cryptic error message.  She could overcome
this with an appropriate (require ...) or (eval-after-load ...) form,
but of what feature?  Should she read the CC Mode source to untangle
the dependencies in order to find the appropriate top-level feature
(and maybe go down the rabbit hole of investigating how the unfamiliar
`cc-require' differs from `require')?  I could only manage to disable
this feature permanently by reading the source and setq-default'ing
(because it's not customizable either) an undocumented variable.

I suspect that if you don't hear many complaints about this behavior
it's because the procedure to disable it is beyond the ability of most
newbies who might wish to do so--perhaps they don't even realize that
it's possible--and that a good number of them move on to some other
editor as a result.  Others of us read the source code and find the right
magic undocumented variable to nilify to make editing C stop being
annoying without complaining to anybody.

[-- Attachment #2: Type: text/html, Size: 3520 bytes --]

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

[Stefan Monnier]

>> For people who don't like electric-indent-mode, CC-mode's
>> c-electric-flag sucks just as much.
> Who are they, except for you?  Why don't we hear any complaints about
> that, except from you?

Hey, guys.  What are you waiting for on the bug-report requesting to
change the default of electric-indent-mode?
Really!


        Stefan

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

[Josh]

[-- Attachment #1: Type: text/plain, Size: 7549 bytes --]

On Sat, Oct 5, 2013 at 9:50 AM, Alan Mackenzie <acm@muc.de> wrote:
> On Fri, Oct 04, 2013 at 02:21:22PM -0700, Josh wrote:
> > On Thu, Oct 3, 2013 at 7:32 AM, Stefan Monnier <monnier@iro.umontreal.ca
>
> > 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.

Sorry, I don't follow.  Why "moderately close" instead of "very
close"?  The docstring of `electric-indent-functions' suggests that
its members are called after the insertion of every character.

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?

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.

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

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.  The fact that you say it would be a lot of work to
rearrange things leads me to believe that my supposition may have been
incorrect, though that does not affect my view that global electricity
settings should govern electricity behavior globally.

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

Since you didn't point out any shortcomings of these mechanisms or
describe these "other means" or why it would be so difficult to
integrate them with global electricity settings, I see no way to
continue this line of discussion.

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

with a corresponding

  (defcustom c-force-electric-flag nil
    "*If non-nil, force electric indentation and newline insertion
enablement.

  Otherwise, the default state of this behavior is to be enabled if either
  `electric-layout-mode' or `electric-indent-mode' are enabled.

  Note: regardless of any of the above settings, `c-toggle-electric-state'
  can toggle enablement of this feature on a buffer-granular basis."
    :type 'boolean
    :group 'c)

though this is imperfect since it loses information when the two
global configuration values differ.  Even so, it would be a vast
improvement for newbies who do not want this behavior.  Another
possible flaw with this approach is that runtime changes to global
electricity enablement would not affect CC Mode's behavior, which
doesn't matter to me but might to others.

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

You're right; I should have said, "I ensured that it was disabled."  I
meant that I had read the relevant documentation and verified that the
all of the related configuration reflected my wishes.  In this case
because the defaults already did so I did not have to change anything.

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

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

I believe even the stopgap measure I suggested would permit changing
that behavior buffer-locally.

[-- Attachment #2: Type: text/html, Size: 8883 bytes --]

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

[Alan Mackenzie]

Hi, Josh.

On Sat, Oct 05, 2013 at 10:04:00PM -0700, Josh wrote:
> On Sat, Oct 5, 2013 at 7:55 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > > Date: Sat, 05 Oct 2013 21:10:01 -0400
> > > Cc: gnu-emacs-bug@moderators.isc.org
> > > For people who don't like electric-indent-mode, CC-mode's
> > > c-electric-flag sucks just as much.
> > Who are they, except for you?  Why don't we hear any complaints about
> > that, except from you?

>     c-electric-flag is a variable defined in `cc-engine.el'.
>     Its value is t

>       Automatically becomes buffer-local when set.

>     Documentation:
>     Not documented as a variable.

> Do you hear many complaints about other undocumented variables?

Here, the variable need only be accessed through the function below.  The
emphasis on this variable is only in discussions like this one, not in
user facilities.

>     C-c C-l runs the command c-toggle-electric-state, which is an
>     interactive compiled Lisp function in `cc-cmds.el'.

>     It is bound to C-c C-l, <menu-bar> <C> <Toggle...> <Electric mode>.

>     (c-toggle-electric-state &optional ARG)

>     Toggle the electric indentation feature.
>     Optional numeric ARG, if supplied, turns on electric indentation when
>     positive, turns it off when negative, and just toggles it when zero or
>     left out.

> This is the command that Alan has claimed solved the problem back in
> 2005 and makes it easy for newbies to easily disable electricity.  I
> don't believe that is so.  Neglecting the fact that newbies are
> unlikely to be familiar with Emacs' "electric" term of art and thus
> unlikely to even make the connection between "c-toggle-electric-state"
> and the behavior they're trying to disable, this docstring makes no
> mention whatsoever of `c-electric-flag', nor does it describe how to
> disable electric behavior permanently.  (One might reasonably assume
> that the global setting would govern here, but as we know it does
> not.)  Perhaps the newbie would have enough Lisp to make the leap from
> that docstring to adding
>   (c-toggle-electric-state -1)
> to her init file, but since that function is not autoloaded it would
> likely only result in a cryptic error message.  She could overcome
> this with an appropriate (require ...) or (eval-after-load ...) form,
> but of what feature?  Should she read the CC Mode source to untangle
> the dependencies in order to find the appropriate top-level feature
> (and maybe go down the rabbit hole of investigating how the unfamiliar
> `cc-require' differs from `require')?  I could only manage to disable
> this feature permanently by reading the source and setq-default'ing
> (because it's not customizable either) an undocumented variable.

Discoverability is a difficulty with lots of things in Emacs.
`c-toggle-electric-state' is fully documented in the CC Mode manual on
the page "Getting Started" (which defines the term "electric
indentation" and indicates how to disable it for all CC Mode buffers),
and there is a link to this from the "FAQ" page.  Read it!

> I suspect that if you don't hear many complaints about this behavior
> it's because the procedure to disable it is beyond the ability of most
> newbies who might wish to do so--perhaps they don't even realize that
> it's possible--and that a good number of them move on to some other
> editor as a result.

When I first started using Emacs (~1996), not only was electric
indentation enabled, but also auto-newline, too.  I found out soon enough
how to disable the latter (which irritated me).

> Others of us read the source code and find the right magic undocumented
> variable to nilify to make editing C stop being annoying without
> complaining to anybody.

Indeed.  Other people ask on help-gnu-emacs.  It's a problem.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, Stefan.

On Sat, Oct 05, 2013 at 09:10:01PM -0400, Stefan Monnier wrote:
> > The default for CC Mode must be on, otherwise automatic indentation
> > is broken.

> IIUC your notion of "automatic indentation" is that the text is kept
> indented without the user hitting TAB, just as a side-effect of editing
> the text.

Yes.

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

> But while CC-mode has been doing that for "ever", it's not nearly as
> important as you claim, as demonstrated by all the other major modes
> that don't even try to do that.

There's a difference between a feature never having been implemented, and
taking it away (even the default value) after it has.  Electric
indentation was in CC Mode in the very first version I have available,
from 1992.  Somebody (RMS?  Barry Warsaw?) clearly thought it very
important.

> > > Please, let's keep this bug-report's focus: making cc-mode obey
> > > electric-indent-mode.  Discussion of default setting of
> > > electric-indent-mode belongs elsewhere.
> > These two things are inextricably entangled.

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

> So, for the sake of it, from here on, let's please continue this
> discussion under the premise that electric-indent-mode will be enabled
> by default.

OK.

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

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'?  What about defining a property
`no-electric-indentation' which could be set on python-mode and others?

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

> I delayed touching at cc-mode mostly because I know you're
> very opinionated ;-)

:-).  

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

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 <acm@muc.de> wrote:
> > On Fri, Oct 04, 2013 at 02:21:22PM -0700, Josh wrote:
> > > On Thu, Oct 3, 2013 at 7:32 AM, Stefan Monnier <monnier@iro.umontreal.ca

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

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

[Eli Zaretskii]

> Date: Mon, 7 Oct 2013 09:39:00 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>,
>   gnu-emacs-bug@moderators.isc.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Hi, Josh.
> 
> On Sat, Oct 05, 2013 at 10:04:00PM -0700, Josh wrote:
> > On Sat, Oct 5, 2013 at 7:55 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > > > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > > > Date: Sat, 05 Oct 2013 21:10:01 -0400
> > > > Cc: gnu-emacs-bug@moderators.isc.org
> > > > For people who don't like electric-indent-mode, CC-mode's
> > > > c-electric-flag sucks just as much.
> > > Who are they, except for you?  Why don't we hear any complaints about
> > > that, except from you?
> 
> >     c-electric-flag is a variable defined in `cc-engine.el'.
> >     Its value is t
> 
> >       Automatically becomes buffer-local when set.
> 
> >     Documentation:
> >     Not documented as a variable.
> 
> > Do you hear many complaints about other undocumented variables?
> 
> Here, the variable need only be accessed through the function below.  The
> emphasis on this variable is only in discussions like this one, not in
> user facilities.

Right.  And in any case, I meant complaints about the behavior, not
about the variables/functions that control it.

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

[Stefan Monnier]

>> 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,
electric-layout-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.


        Stefan

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

[Alan Mackenzie]

'Evening, Stefan.

On Mon, Oct 07, 2013 at 12:14:19PM -0400, Stefan Monnier wrote:
> >> 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.

Electric indentation only works on the current line, and I'm not sure
extending it to subsequent lines would be a good idea.  Could you specify
cases where it doesn't work on the current line?

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

How do they fail?

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

;-).  That, you should have expected. It's a standard conflict of
interests - those of Emacs (as a whole) against those of the individual
modes.  Having all the arguments, though, will result in a better
electric-indent-mode which interacts better with the other modes.

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

Do you want to elaborate?

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

Electric indentation is precisely about the *re*indation of the current
line, isn't it?  indent-according-to-mode after NL isn't electric
indentation.

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

OK, I'll do this.

> 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,
> electric-layout-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.

OK.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Josh]

[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]

On Mon, Oct 7, 2013 at 9:05 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Mon, 7 Oct 2013 09:39:00 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <
> monnier@iro.umontreal.ca>,
> >   gnu-emacs-bug@moderators.isc.org
> > From: Alan Mackenzie <acm@muc.de>
> >
> > Hi, Josh.
> >
> > On Sat, Oct 05, 2013 at 10:04:00PM -0700, Josh wrote:
> > > On Sat, Oct 5, 2013 at 7:55 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > > > > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > > > > Date: Sat, 05 Oct 2013 21:10:01 -0400
> > > > > Cc: gnu-emacs-bug@moderators.isc.org
> > > > > For people who don't like electric-indent-mode, CC-mode's
> > > > > c-electric-flag sucks just as much.
> > > > Who are they, except for you?  Why don't we hear any complaints about
> > > > that, except from you?
> >
> > >     c-electric-flag is a variable defined in `cc-engine.el'.
> > >     Its value is t
> >
> > >       Automatically becomes buffer-local when set.
> >
> > >     Documentation:
> > >     Not documented as a variable.
> >
> > > Do you hear many complaints about other undocumented variables?
> >
> > Here, the variable need only be accessed through the function below.  The
> > emphasis on this variable is only in discussions like this one, not in
> > user facilities.
>
> Right.  And in any case, I meant complaints about the behavior, not
> about the variables/functions that control it.
>

I know what you meant.  The reason I pointed out the fact that that the
variable that supposedly "solved" this is undocumented, that newbies will
not recognize "electric" as pertinent, and all the rest of it is to show
that disabling this behavior is far too arcane and burdensome for newbies.
As Daniel said upthread, "Users don't read READMEs --- they download a
program, try it out, and in 15 minutes or so, decide whether they want to
invest time into it."  I believe that most such users who dislike this
behavior and start down the path I described will fail and be far less
likely to invest further time in Emacs and move on to something else.
Perhaps such users are a small minority; I don't know.  But I attribute the
fact that you see few complaints about this behavior to selection bias,
with some who dislike the behavior not complaining because they gave up and
moved on to another editor while still others who dislike it do not
complain because we managed to disable it ourselves.

[-- Attachment #2: Type: text/html, Size: 3425 bytes --]

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

[Josh]

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.

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

[Stefan Monnier]

>> 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.
> Electric indentation only works on the current line, and I'm not sure
> extending it to subsequent lines would be a good idea.  Could you specify
> cases where it doesn't work on the current line?

I don't care to try and remember the cases where TAB is needed, because
hitting TAB is like second nature anyway, but at least C-y and M-d are
obvious cases.

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

They leave the code mis-indented because the action did not
trigger reindentation.

>> > 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.
> Do you want to elaborate?

Off hand, things lacking compared to the ideal:
- the keys should be bound to self-insert-command.
- the user should be able to control the behavior via electric-indent-chars,
  like with all other modes.
but as I said, it does satisfy the requirements.

> Electric indentation is precisely about the *re*indation of the current
> line, isn't it?  indent-according-to-mode after NL isn't electric
> indentation.

It is very much part of electric-indent-mode (the default value of
electric-indent-chars is just '(?\n)).


        Stefan

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

[Eli Zaretskii]

> From: Josh <josh@foxtail.org>
> Date: Mon, 7 Oct 2013 14:17:23 -0700
> Cc: Alan Mackenzie <acm@muc.de>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	gnu-emacs-bug@moderators.isc.org
> 
> > > > Do you hear many complaints about other undocumented variables?
> > >
> > > Here, the variable need only be accessed through the function below.  The
> > > emphasis on this variable is only in discussions like this one, not in
> > > user facilities.
> >
> > Right.  And in any case, I meant complaints about the behavior, not
> > about the variables/functions that control it.
> 
> I know what you meant.  The reason I pointed out the fact that that the
> variable that supposedly "solved" this is undocumented, that newbies will
> not recognize "electric" as pertinent, and all the rest of it is to show
> that disabling this behavior is far too arcane and burdensome for newbies.

I know what you wanted to point out.  What I want to point out is that
people complain about inconvenient behavior even if (and mostly
_because_) they cannot find how to disable it.  Existence of obscure
variables, or lack thereof, is never a reason _not_ to complain.

> As Daniel said upthread, "Users don't read READMEs --- they download a
> program, try it out, and in 15 minutes or so, decide whether they want to
> invest time into it."  I believe that most such users who dislike this
> behavior and start down the path I described will fail and be far less
> likely to invest further time in Emacs and move on to something else.
> Perhaps such users are a small minority; I don't know.  But I attribute the
> fact that you see few complaints about this behavior to selection bias,
> with some who dislike the behavior not complaining because they gave up and
> moved on to another editor while still others who dislike it do not
> complain because we managed to disable it ourselves.

This hypothesis is not useful, because it can "justify" any opinion,
without being burdened with any evidence whatsoever.  The fact is that
users do complain about all sorts of Emacs behavior that is
inconvenient for them.  So, as a matter of fact, enough users do
survive the 15-minute shock to continue using Emacs.  If most of those
who do don't see the current electrical behavior as a nuisance worth
complaining about, that is good enough for me.

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

[Josh]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

On Mon, Oct 7, 2013 at 11:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Josh <josh@foxtail.org>
> > Date: Mon, 7 Oct 2013 14:17:23 -0700
> > Cc: Alan Mackenzie <acm@muc.de>, Stefan Monnier <
monnier@iro.umontreal.ca>,
> >       gnu-emacs-bug@moderators.isc.org
> > As Daniel said upthread, "Users don't read READMEs --- they download a
> > program, try it out, and in 15 minutes or so, decide whether they want
to
> > invest time into it."  I believe that most such users who dislike this
> > behavior and start down the path I described will fail and be far less
> > likely to invest further time in Emacs and move on to something else.
> > Perhaps such users are a small minority; I don't know.  But I attribute
the
> > fact that you see few complaints about this behavior to selection bias,
> > with some who dislike the behavior not complaining because they gave up
and
> > moved on to another editor while still others who dislike it do not
> > complain because we managed to disable it ourselves.
> This hypothesis is not useful, because it can "justify" any opinion,
> without being burdened with any evidence whatsoever.  The fact is that
> users do complain about all sorts of Emacs behavior that is
> inconvenient for them.  So, as a matter of fact, enough users do
> survive the 15-minute shock to continue using Emacs.  If most of those
> who do don't see the current electrical behavior as a nuisance worth
> complaining about, that is good enough for me.

The squeaky wheel metric is often useful but surely you would agree
that it tends to underrepresent those problems that are unlikely to
be complained about in practice for one reason or another.  I offered
two such reasons (and you'll note that I acknowledged the possibility
that such users could be a small minority) in order to point out that
the number of complaints alone may not reflect the full extent of the
problem, but it's clear that you don't believe the difference matters
in this case.

[-- Attachment #2: Type: text/html, Size: 2510 bytes --]

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

[Alan Mackenzie]

Hi, Josh.

On Mon, Oct 07, 2013 at 02:17:23PM -0700, Josh wrote:
> On Mon, Oct 7, 2013 at 9:05 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > > On Sat, Oct 05, 2013 at 10:04:00PM -0700, Josh wrote:
> > > > On Sat, Oct 5, 2013 at 7:55 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > > > > > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > > > > > Date: Sat, 05 Oct 2013 21:10:01 -0400
> > > > > > Cc: gnu-emacs-bug@moderators.isc.org
> > > > > > For people who don't like electric-indent-mode, CC-mode's
> > > > > > c-electric-flag sucks just as much.
> > > > > Who are they, except for you?  Why don't we hear any complaints about
> > > > > that, except from you?

> > > >     c-electric-flag is a variable defined in `cc-engine.el'.
> > > >     Its value is t

> > > >       Automatically becomes buffer-local when set.

> > > >     Documentation:
> > > >     Not documented as a variable.

> > > > Do you hear many complaints about other undocumented variables?

> > > Here, the variable need only be accessed through the function below.  The
> > > emphasis on this variable is only in discussions like this one, not in
> > > user facilities.

> > Right.  And in any case, I meant complaints about the behavior, not
> > about the variables/functions that control it.


> I know what you meant.  The reason I pointed out the fact that that the
> variable that supposedly "solved" this is undocumented, that newbies will
> not recognize "electric" as pertinent, and all the rest of it is to show
> that disabling this behavior is far too arcane and burdensome for newbies.

This is getting tiresome.  The variable `c-electric-flag', strictly
speaking, isn't documented, but the command whose entire purpose is to
set it is fully documented in the CC Mode manual (have you read this
yet?) in the chapter directed at newbies.  Not only is it documented, it
is present in the Emacs menu under C/toggle/electric mode, a place
newbies are likely to look.  I think most of them will be able to guess
what "electric mode" means, and if not, they are likely to try it out to
see if it helps.

> As Daniel said upthread, "Users don't read READMEs --- they download a
> program, try it out, and in 15 minutes or so, decide whether they want to
> invest time into it."  I believe that most such users who dislike this
> behavior and start down the path I described will fail and be far less
> likely to invest further time in Emacs and move on to something else.
> Perhaps such users are a small minority; I don't know.  But I attribute the
> fact that you see few complaints about this behavior to selection bias,
> with some who dislike the behavior not complaining because they gave up and
> moved on to another editor while still others who dislike it do not
> complain because we managed to disable it ourselves.

I think you are wrong here.  Before the implementation of
`c-toggle-electric-state', there were several complaints about the
difficulty of turning off electric indentation in CC Mode.  Since then,
there have been none that I'm aware of, apart from this one.  This
suggests that users are capable of finding out about this facility and
that they find it adequate.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hi, Josh.

On Mon, Oct 07, 2013 at 02:23:20PM -0700, Josh wrote:
> On Mon, Oct 7, 2013 at 6:11 AM, Alan Mackenzie <acm@muc.de> wrote:

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

No, but there haven't been arguments that CC Mode's default for electric
indentation is wrong, and there certainly hasn't been a bug report saying
that.  Users seem to be happy about the current default.  I'm convinced
that electric indentation switched on is the right default for CC Mode,
for the same reasons that gave rise to its invention in the first place,
in all probability.

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

But the solution is not to disregard other bits of documented
configuration instead.  Local, specific configurations generally
supersede global, general configurations.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Josh]

On Wed, Oct 9, 2013 at 10:32 AM, Alan Mackenzie <acm@muc.de> wrote:
> This is getting tiresome.  The variable `c-electric-flag', strictly
> speaking, isn't documented, but the command whose entire purpose is to
> set it is fully documented in the CC Mode manual (have you read this
> yet?) in the chapter directed at newbies.  Not only is it documented, it
> is present in the Emacs menu under C/toggle/electric mode, a place
> newbies are likely to look.  I think most of them will be able to guess
> what "electric mode" means, and if not, they are likely to try it out to
> see if it helps.

I have read the manual and found no mention of how to permanently
disable the behavior, which is why in the end I was forced to read the
source to find a solution.  At any rate I agree that this has become
tiresome and I'll not belabor the point any further.

bug#15596: Let's improve the default workings of electric-indent-mode.

[Alan Mackenzie]

Hi, Stefan.

On Sun, Oct 06, 2013 at 01:01:31PM -0400, Stefan Monnier wrote:
> Hey, guys.  What are you waiting for on the bug-report requesting to
> change the default of electric-indent-mode?
> Really!

I think the default behaviour of electric-indent-mode can and should be
improved.

At the moment, it is (rather crudely) just nil or t, globally for all
modes and all buffers.  This is unsatisfactory, as it makes it difficult
to {en,dis}able e-i-m for a single mode, and for a single buffer.  An
example of when you might want to do the latter is thus: one has an
isolated file.c (or section therewithin) whose indentation style does not
conform to project norms, and one does not wish to reindent the file
wholesale.  Electric indentation makes editing such a file inconvenient,
hence the need for the ability readily to switch it off (currently
available in CC Mode with C-c C-l).

We need a method of {en,dis}abling e-i-m for both modes and for indiviual
buffers.  We probably don't want to change the definition of the variable
`electric-indent-mode'.

So, make `electric-indent-mode' t by default, yet have it tempered by the
new buffer local variables `electric-indent-enabled-function' and
`electric-indent-enabled-flag', both defaulting to nil, which work in the
canonical Emacs fashion.  These variables will be intended mainly for
mode maintainers, yet will be available to knowledgeable users for
configuration/toggling.  When `e-i-m' is t and one of these new variables
returns/is t, then electric indentation will take place.

With this scheme, users can globally disable e-i-m by toggling
electric-indent-mode, as at present.  They can enable it in all buffers
in which it makes sense by toggling it again.  They can enable it in
other buffers by setting `electric-indent-enabled-flag' in those buffers.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#15596: Let's improve the default workings of electric-indent-mode.

[Stefan Monnier]

> At the moment, it is (rather crudely) just nil or t, globally for all
> modes and all buffers.  This is unsatisfactory, as it makes it difficult
> to {en,dis}able e-i-m for a single mode, and for a single buffer.  An
> example of when you might want to do the latter is thus: one has an
> isolated file.c (or section therewithin) whose indentation style does not
> conform to project norms, and one does not wish to reindent the file
> wholesale.  Electric indentation makes editing such a file inconvenient,
> hence the need for the ability readily to switch it off (currently
> available in CC Mode with C-c C-l).

Currently it's easyish for the user to do

   (add-hook 'blabla-hook
             (lambda () (setq-local electric-indent-mode nil)))

Or to set electric-indent-mode to nil in the file variables.

But we could provide an electric-indent-local-mode, yes.  Patch welcome.

> So, make `electric-indent-mode' t by default, yet have it tempered by the

Have any one of you tried to use Emacs with this setting?  I'm not
fundamentally opposed to changing the default setting, but just as was
the case for font-lock-mode, transient-mark-mode, etc... we need to be
sure it actually works well enough in "all" cases (except those cases
where the user just doesn't like the feature and will disable it
globally).
But contrary to font-lock-mode, transient-mark-mode, AFAIK not many
people have enabled this mode yet, so I'd urge you all to try it out for
a few weeks first, to see if you like it not only in modes like c-mode
but also everywhere else, and if there are cases where you find it
inconvenient, report it here, so we can see what we should do about it.

> new buffer local variables `electric-indent-enabled-function' and

The buffer-local value of electric-indent-mode is already used for
that purpose (and there's also the new electric-indent-inhibit which
I recently added, which prevents reindentation, while still doing
automatic indentation for new lines.


        Stefan

bug#15596: Let's improve the default workings of electric-indent-mode.

[Alan Mackenzie]

Hello, Stefan.

On Sat, Oct 12, 2013 at 12:35:46PM -0400, Stefan Monnier wrote:
> > At the moment, it is (rather crudely) just nil or t, globally for all
> > modes and all buffers.  This is unsatisfactory, as it makes it difficult
> > to {en,dis}able e-i-m for a single mode, and for a single buffer.  An
> > example of when you might want to do the latter is thus: one has an
> > isolated file.c (or section therewithin) whose indentation style does not
> > conform to project norms, and one does not wish to reindent the file
> > wholesale.  Electric indentation makes editing such a file inconvenient,
> > hence the need for the ability readily to switch it off (currently
> > available in CC Mode with C-c C-l).

> Currently it's easyish for the user to do

>    (add-hook 'blabla-hook
>              (lambda () (setq-local electric-indent-mode nil)))

> Or to set electric-indent-mode to nil in the file variables.

These are surely bad ideas.  `electric-indent-mode' is a global mode, so
creating buffer local copies of it will lead to confusion.  What does M-x
electric-indent-mode do when there's a buffer local value of e-i-m?  If
it toggles the global binding, it will appear not to have worked in the
current buffer.  If it toggles the local binding, it is no longer a
global mode.  This is why I suggested extra variables to handle locality
(see below).

> But we could provide an electric-indent-local-mode, yes.  Patch welcome.

> > So, make `electric-indent-mode' t by default, yet have it tempered by the

> Have any one of you tried to use Emacs with this setting?  I'm not
> fundamentally opposed to changing the default setting, but just as was
> the case for font-lock-mode, transient-mark-mode, etc... we need to be
> sure it actually works well enough in "all" cases (except those cases
> where the user just doesn't like the feature and will disable it
> globally).

I think I was a bit unclear.  I meant have the _variable_ e-i-m set to t
by default, but have the electricity disabled by default by the new
buffer local variable `electric-indent-enabled-flag'.  But the new
variable `electric-indent-inhibit' can do this anyhow.

> But contrary to font-lock-mode, transient-mark-mode, AFAIK not many
> people have enabled this mode yet, so I'd urge you all to try it out for
> a few weeks first, to see if you like it not only in modes like c-mode
> but also everywhere else, and if there are cases where you find it
> inconvenient, report it here, so we can see what we should do about it.

As I reported in emacs-devel, I had trouble in Text Mode with e-i-m.

> > new buffer local variables `electric-indent-enabled-function' and

> The buffer-local value of electric-indent-mode is already used for
> that purpose .....

I think this is a bad thing (see above), and such uses should be
superseded by using ...

> ... (and there's also the new electric-indent-inhibit which I recently
> added, which prevents reindentation, while still doing automatic
> indentation for new lines.

Surely e-i-inhibit should be t by default.  Electric indentation is
useful in (?most) programming modes, but probably not very much in text
modes, or things like Outline Mode.  It is useful precisely where the
indentation of a line is determined by that same line's contents.
(That's not counting the `newline-and-indent' behaviour.) That surely
happens only in programming modes, or the like.  How about having
e-i-inhibit t by default, but setting it to nil in `prog-mode'?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#15596: Let's improve the default workings of electric-indent-mode.

[Stefan Monnier]

> These are surely bad ideas.  `electric-indent-mode' is a global mode, so
> creating buffer local copies of it will lead to confusion.

It's not meant for purely interactive use (and indeed it requires Elisp
coding), and for programmatic uses there's no reason why it should lead
to confusion.

> What does M-x electric-indent-mode do when there's a buffer local
> value of e-i-m?  If it toggles the global binding, it will appear not
> to have worked in the current buffer.

Presumably the user who added the buffer-local binding knows what it does.

> If it toggles the local binding, it is no longer a global mode.

Indeed, that would be a bug.

> I think I was a bit unclear.  I meant have the _variable_ e-i-m set to t
> by default, but have the electricity disabled by default by the new
> buffer local variable `electric-indent-enabled-flag'.  But the new
> variable `electric-indent-inhibit' can do this anyhow.

I'm not sure I understand what we're talking about, then:
when you wrote "make `electric-indent-mode' t by default" I understood
it to mean that the default behavior of Emacs in most modes should be to
auto-indent.

> As I reported in emacs-devel, I had trouble in Text Mode with e-i-m.

Maybe we should make text-mode disable electric-indent-mode by default?

> Surely e-i-inhibit should be t by default.  Electric indentation is
> useful in (?most) programming modes, but probably not very much in text
> modes, or things like Outline Mode.

In practice, it's already the case for those modes, AFAIK (tho not by
setting e-i-inhibit, because that feature existed before e-i-inhibit).

> How about having e-i-inhibit t by default, but setting it to nil in
> `prog-mode'?

I could consider that.  But if we can do without it, that would be
preferable, since many programming modes don't derive from prog-mode
(yet), and several non-programming modes support indentation
(e.g. latex-mode, change-log-mode).


        Stefan

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

[Alan Mackenzie]

Enhancement done.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

> Enhancement done.

Thanks,


        Stefan