* bug#15478: cc-mode does not obey electric-indent-mode @ 2013-09-28 18:10 Stefan Monnier 2013-09-28 20:11 ` Alan Mackenzie ` (5 more replies) 0 siblings, 6 replies; 53+ messages in thread From: Stefan Monnier @ 2013-09-28 18:10 UTC (permalink / raw) To: 15478 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) ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-09-28 18:10 bug#15478: cc-mode does not obey electric-indent-mode Stefan Monnier @ 2013-09-28 20:11 ` Alan Mackenzie 2013-09-29 3:02 ` Stefan Monnier 2013-10-03 11:54 ` Alan Mackenzie ` (4 subsequent siblings) 5 siblings, 1 reply; 53+ messages in thread From: Alan Mackenzie @ 2013-09-28 20:11 UTC (permalink / raw) To: Stefan Monnier; +Cc: 15478 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-09-28 20:11 ` Alan Mackenzie @ 2013-09-29 3:02 ` Stefan Monnier 2013-09-29 9:10 ` Alan Mackenzie 0 siblings, 1 reply; 53+ messages in thread From: Stefan Monnier @ 2013-09-29 3:02 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 15478 > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-09-29 3:02 ` Stefan Monnier @ 2013-09-29 9:10 ` Alan Mackenzie 2013-09-30 18:23 ` Stefan Monnier 0 siblings, 1 reply; 53+ messages in thread From: Alan Mackenzie @ 2013-09-29 9:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: 15478 '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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-09-29 9:10 ` Alan Mackenzie @ 2013-09-30 18:23 ` Stefan Monnier 2013-10-02 20:07 ` Alan Mackenzie 0 siblings, 1 reply; 53+ messages in thread From: Stefan Monnier @ 2013-09-30 18:23 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 15478 > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-09-30 18:23 ` Stefan Monnier @ 2013-10-02 20:07 ` Alan Mackenzie 2013-10-03 1:50 ` Stefan Monnier 0 siblings, 1 reply; 53+ messages in thread From: Alan Mackenzie @ 2013-10-02 20:07 UTC (permalink / raw) To: Stefan Monnier; +Cc: 15478 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-02 20:07 ` Alan Mackenzie @ 2013-10-03 1:50 ` Stefan Monnier 2013-10-03 2:46 ` Daniel Colascione 2013-10-03 10:56 ` Alan Mackenzie 0 siblings, 2 replies; 53+ messages in thread From: Stefan Monnier @ 2013-10-03 1:50 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 15478 > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 1:50 ` Stefan Monnier @ 2013-10-03 2:46 ` Daniel Colascione 2013-10-03 4:10 ` Stefan Monnier 2013-10-03 10:56 ` Alan Mackenzie 1 sibling, 1 reply; 53+ messages in thread From: Daniel Colascione @ 2013-10-03 2:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: 15478, Alan Mackenzie [-- 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 2:46 ` Daniel Colascione @ 2013-10-03 4:10 ` Stefan Monnier 2013-10-03 4:13 ` Daniel Colascione ` (2 more replies) 0 siblings, 3 replies; 53+ messages in thread From: Stefan Monnier @ 2013-10-03 4:10 UTC (permalink / raw) To: Daniel Colascione; +Cc: 15478, Alan Mackenzie >> 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 4:10 ` Stefan Monnier @ 2013-10-03 4:13 ` Daniel Colascione 2013-10-03 4:50 ` Stefan Monnier 2013-10-03 5:56 ` Andreas Röhler 2013-10-03 9:45 ` Alan Mackenzie 2 siblings, 1 reply; 53+ messages in thread From: Daniel Colascione @ 2013-10-03 4:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: 15478, Alan Mackenzie [-- 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 4:13 ` Daniel Colascione @ 2013-10-03 4:50 ` Stefan Monnier 0 siblings, 0 replies; 53+ messages in thread From: Stefan Monnier @ 2013-10-03 4:50 UTC (permalink / raw) To: Daniel Colascione; +Cc: 15478, Alan Mackenzie > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 4:10 ` Stefan Monnier 2013-10-03 4:13 ` Daniel Colascione @ 2013-10-03 5:56 ` Andreas Röhler 2013-10-03 6:31 ` Daniel Colascione 2013-10-03 13:15 ` Dmitry Gutov 2013-10-03 9:45 ` Alan Mackenzie 2 siblings, 2 replies; 53+ messages in thread From: Andreas Röhler @ 2013-10-03 5:56 UTC (permalink / raw) To: 15478 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 5:56 ` Andreas Röhler @ 2013-10-03 6:31 ` Daniel Colascione 2013-10-03 15:52 ` Eli Zaretskii 2013-10-03 13:15 ` Dmitry Gutov 1 sibling, 1 reply; 53+ messages in thread From: Daniel Colascione @ 2013-10-03 6:31 UTC (permalink / raw) To: Andreas Röhler; +Cc: 15478 [-- 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 6:31 ` Daniel Colascione @ 2013-10-03 15:52 ` Eli Zaretskii 0 siblings, 0 replies; 53+ messages in thread From: Eli Zaretskii @ 2013-10-03 15:52 UTC (permalink / raw) To: Daniel Colascione; +Cc: 15478 > 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".) ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 5:56 ` Andreas Röhler 2013-10-03 6:31 ` Daniel Colascione @ 2013-10-03 13:15 ` Dmitry Gutov 2013-10-03 15:04 ` Stefan Monnier 2013-10-03 17:40 ` Andreas Röhler 1 sibling, 2 replies; 53+ messages in thread From: Dmitry Gutov @ 2013-10-03 13:15 UTC (permalink / raw) To: Andreas Röhler; +Cc: 15478 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". ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 13:15 ` Dmitry Gutov @ 2013-10-03 15:04 ` Stefan Monnier 2013-10-03 17:40 ` Andreas Röhler 1 sibling, 0 replies; 53+ messages in thread From: Stefan Monnier @ 2013-10-03 15:04 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 15478 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 13:15 ` Dmitry Gutov 2013-10-03 15:04 ` Stefan Monnier @ 2013-10-03 17:40 ` Andreas Röhler 1 sibling, 0 replies; 53+ messages in thread From: Andreas Röhler @ 2013-10-03 17:40 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 15478 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 4:10 ` Stefan Monnier 2013-10-03 4:13 ` Daniel Colascione 2013-10-03 5:56 ` Andreas Röhler @ 2013-10-03 9:45 ` Alan Mackenzie 2013-10-03 14:02 ` Stefan Monnier 2013-10-03 17:45 ` Andreas Röhler 2 siblings, 2 replies; 53+ messages in thread From: Alan Mackenzie @ 2013-10-03 9:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: 15478 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 9:45 ` Alan Mackenzie @ 2013-10-03 14:02 ` Stefan Monnier 2013-10-03 17:45 ` Andreas Röhler 1 sibling, 0 replies; 53+ messages in thread From: Stefan Monnier @ 2013-10-03 14:02 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 15478 > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 9:45 ` Alan Mackenzie 2013-10-03 14:02 ` Stefan Monnier @ 2013-10-03 17:45 ` Andreas Röhler 1 sibling, 0 replies; 53+ messages in thread From: Andreas Röhler @ 2013-10-03 17:45 UTC (permalink / raw) To: 15478 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 1:50 ` Stefan Monnier 2013-10-03 2:46 ` Daniel Colascione @ 2013-10-03 10:56 ` Alan Mackenzie 2013-10-03 14:32 ` Stefan Monnier 1 sibling, 1 reply; 53+ messages in thread From: Alan Mackenzie @ 2013-10-03 10:56 UTC (permalink / raw) To: Stefan Monnier; +Cc: 15478 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 10:56 ` Alan Mackenzie @ 2013-10-03 14:32 ` Stefan Monnier 2013-10-04 21:21 ` Josh 0 siblings, 1 reply; 53+ messages in thread From: Stefan Monnier @ 2013-10-03 14:32 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 15478 >> > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 14:32 ` Stefan Monnier @ 2013-10-04 21:21 ` Josh 2013-10-05 16:50 ` Alan Mackenzie 0 siblings, 1 reply; 53+ messages in thread From: Josh @ 2013-10-04 21:21 UTC (permalink / raw) To: Stefan Monnier; +Cc: 15478, Alan Mackenzie [-- 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-04 21:21 ` Josh @ 2013-10-05 16:50 ` Alan Mackenzie 2013-10-06 17:45 ` Josh 0 siblings, 1 reply; 53+ messages in thread From: Alan Mackenzie @ 2013-10-05 16:50 UTC (permalink / raw) To: Josh; +Cc: 15478 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-05 16:50 ` Alan Mackenzie @ 2013-10-06 17:45 ` Josh 2013-10-07 13:11 ` Alan Mackenzie 0 siblings, 1 reply; 53+ messages in thread From: Josh @ 2013-10-06 17:45 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 15478 [-- 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-06 17:45 ` Josh @ 2013-10-07 13:11 ` Alan Mackenzie 2013-10-07 21:23 ` Josh 0 siblings, 1 reply; 53+ messages in thread From: Alan Mackenzie @ 2013-10-07 13:11 UTC (permalink / raw) To: Josh; +Cc: 15478 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-07 13:11 ` Alan Mackenzie @ 2013-10-07 21:23 ` Josh 2013-10-09 17:55 ` Alan Mackenzie 0 siblings, 1 reply; 53+ messages in thread From: Josh @ 2013-10-07 21:23 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 15478 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-07 21:23 ` Josh @ 2013-10-09 17:55 ` Alan Mackenzie 0 siblings, 0 replies; 53+ messages in thread From: Alan Mackenzie @ 2013-10-09 17:55 UTC (permalink / raw) To: Josh; +Cc: 15478 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-09-28 18:10 bug#15478: cc-mode does not obey electric-indent-mode Stefan Monnier 2013-09-28 20:11 ` Alan Mackenzie @ 2013-10-03 11:54 ` Alan Mackenzie 2013-10-03 17:43 ` Andreas Röhler 2013-10-05 17:06 ` Alan Mackenzie ` (3 subsequent siblings) 5 siblings, 1 reply; 53+ messages in thread From: Alan Mackenzie @ 2013-10-03 11:54 UTC (permalink / raw) To: gnu-emacs-bug 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-03 11:54 ` Alan Mackenzie @ 2013-10-03 17:43 ` Andreas Röhler 0 siblings, 0 replies; 53+ messages in thread From: Andreas Röhler @ 2013-10-03 17:43 UTC (permalink / raw) To: 15478; +Cc: Alan Mackenzie Am 03.10.2013 13:54, schrieb Alan Mackenzie: > > I say, let the defaults reflect a properly functioning Emacs. > Definitely yours, Andreas ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-09-28 18:10 bug#15478: cc-mode does not obey electric-indent-mode Stefan Monnier 2013-09-28 20:11 ` Alan Mackenzie 2013-10-03 11:54 ` Alan Mackenzie @ 2013-10-05 17:06 ` Alan Mackenzie 2013-10-06 1:10 ` Stefan Monnier 2013-10-05 17:08 ` Alan Mackenzie ` (2 subsequent siblings) 5 siblings, 1 reply; 53+ messages in thread From: Alan Mackenzie @ 2013-10-05 17:06 UTC (permalink / raw) To: gnu-emacs-bug 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-05 17:06 ` Alan Mackenzie @ 2013-10-06 1:10 ` Stefan Monnier 2013-10-06 2:55 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 53+ messages in thread From: Stefan Monnier @ 2013-10-06 1:10 UTC (permalink / raw) To: Alan Mackenzie; +Cc: gnu-emacs-bug > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-06 1:10 ` Stefan Monnier @ 2013-10-06 2:55 ` Eli Zaretskii 2013-10-06 5:04 ` Josh 2013-10-06 17:01 ` Stefan Monnier 2013-10-07 10:30 ` bug#15478: cc-mode does not obey electric-indent-mode Alan Mackenzie [not found] ` <20131007103041.GB3859@acm.acm> 2 siblings, 2 replies; 53+ messages in thread From: Eli Zaretskii @ 2013-10-06 2:55 UTC (permalink / raw) To: Stefan Monnier; +Cc: gnu-emacs-bug, acm > 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? ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-06 2:55 ` Eli Zaretskii @ 2013-10-06 5:04 ` Josh 2013-10-07 9:39 ` Alan Mackenzie [not found] ` <20131007093859.GA3859@acm.acm> 2013-10-06 17:01 ` Stefan Monnier 1 sibling, 2 replies; 53+ messages in thread From: Josh @ 2013-10-06 5:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gnu-emacs-bug, Alan Mackenzie [-- 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-06 5:04 ` Josh @ 2013-10-07 9:39 ` Alan Mackenzie [not found] ` <20131007093859.GA3859@acm.acm> 1 sibling, 0 replies; 53+ messages in thread From: Alan Mackenzie @ 2013-10-07 9:39 UTC (permalink / raw) To: Josh; +Cc: gnu-emacs-bug 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
[parent not found: <20131007093859.GA3859@acm.acm>]
* bug#15478: cc-mode does not obey electric-indent-mode [not found] ` <20131007093859.GA3859@acm.acm> @ 2013-10-07 16:05 ` Eli Zaretskii 2013-10-07 21:17 ` Josh 0 siblings, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2013-10-07 16:05 UTC (permalink / raw) To: Alan Mackenzie; +Cc: gnu-emacs-bug, josh > 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-07 16:05 ` Eli Zaretskii @ 2013-10-07 21:17 ` Josh 2013-10-08 6:49 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 53+ messages in thread From: Josh @ 2013-10-07 21:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gnu-emacs-bug, Alan Mackenzie [-- 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-07 21:17 ` Josh @ 2013-10-08 6:49 ` Eli Zaretskii 2013-10-08 15:59 ` Josh 2013-10-09 17:32 ` Alan Mackenzie [not found] ` <20131009173206.GA2610@acm.acm> 2 siblings, 1 reply; 53+ messages in thread From: Eli Zaretskii @ 2013-10-08 6:49 UTC (permalink / raw) To: Josh; +Cc: gnu-emacs-bug, acm > 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-08 6:49 ` Eli Zaretskii @ 2013-10-08 15:59 ` Josh 0 siblings, 0 replies; 53+ messages in thread From: Josh @ 2013-10-08 15:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gnu-emacs-bug, Alan Mackenzie [-- 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-07 21:17 ` Josh 2013-10-08 6:49 ` Eli Zaretskii @ 2013-10-09 17:32 ` Alan Mackenzie [not found] ` <20131009173206.GA2610@acm.acm> 2 siblings, 0 replies; 53+ messages in thread From: Alan Mackenzie @ 2013-10-09 17:32 UTC (permalink / raw) To: Josh; +Cc: gnu-emacs-bug 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
[parent not found: <20131009173206.GA2610@acm.acm>]
* bug#15478: cc-mode does not obey electric-indent-mode [not found] ` <20131009173206.GA2610@acm.acm> @ 2013-10-10 19:11 ` Josh 0 siblings, 0 replies; 53+ messages in thread From: Josh @ 2013-10-10 19:11 UTC (permalink / raw) To: Alan Mackenzie; +Cc: gnu-emacs-bug 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-06 2:55 ` Eli Zaretskii 2013-10-06 5:04 ` Josh @ 2013-10-06 17:01 ` Stefan Monnier 2013-10-12 14:54 ` bug#15596: Let's improve the default workings of electric-indent-mode Alan Mackenzie 1 sibling, 1 reply; 53+ messages in thread From: Stefan Monnier @ 2013-10-06 17:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gnu-emacs-bug, acm >> 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15596: Let's improve the default workings of electric-indent-mode. 2013-10-06 17:01 ` Stefan Monnier @ 2013-10-12 14:54 ` Alan Mackenzie 2013-10-12 16:35 ` Stefan Monnier 0 siblings, 1 reply; 53+ messages in thread From: Alan Mackenzie @ 2013-10-12 14:54 UTC (permalink / raw) To: 15596 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15596: Let's improve the default workings of electric-indent-mode. 2013-10-12 14:54 ` bug#15596: Let's improve the default workings of electric-indent-mode Alan Mackenzie @ 2013-10-12 16:35 ` Stefan Monnier 2013-10-13 12:36 ` Alan Mackenzie 0 siblings, 1 reply; 53+ messages in thread From: Stefan Monnier @ 2013-10-12 16:35 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 15596 > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15596: Let's improve the default workings of electric-indent-mode. 2013-10-12 16:35 ` Stefan Monnier @ 2013-10-13 12:36 ` Alan Mackenzie 2013-10-14 2:16 ` Stefan Monnier 0 siblings, 1 reply; 53+ messages in thread From: Alan Mackenzie @ 2013-10-13 12:36 UTC (permalink / raw) To: Stefan Monnier; +Cc: 15596 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15596: Let's improve the default workings of electric-indent-mode. 2013-10-13 12:36 ` Alan Mackenzie @ 2013-10-14 2:16 ` Stefan Monnier 0 siblings, 0 replies; 53+ messages in thread From: Stefan Monnier @ 2013-10-14 2:16 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 15596 > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-06 1:10 ` Stefan Monnier 2013-10-06 2:55 ` Eli Zaretskii @ 2013-10-07 10:30 ` Alan Mackenzie [not found] ` <20131007103041.GB3859@acm.acm> 2 siblings, 0 replies; 53+ messages in thread From: Alan Mackenzie @ 2013-10-07 10:30 UTC (permalink / raw) To: Stefan Monnier; +Cc: gnu-emacs-bug 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
[parent not found: <20131007103041.GB3859@acm.acm>]
* bug#15478: cc-mode does not obey electric-indent-mode [not found] ` <20131007103041.GB3859@acm.acm> @ 2013-10-07 16:14 ` Stefan Monnier 2013-10-07 20:37 ` Alan Mackenzie [not found] ` <20131007203738.GA3099@acm.acm> 0 siblings, 2 replies; 53+ messages in thread From: Stefan Monnier @ 2013-10-07 16:14 UTC (permalink / raw) To: Alan Mackenzie; +Cc: gnu-emacs-bug >> 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-10-07 16:14 ` Stefan Monnier @ 2013-10-07 20:37 ` Alan Mackenzie [not found] ` <20131007203738.GA3099@acm.acm> 1 sibling, 0 replies; 53+ messages in thread From: Alan Mackenzie @ 2013-10-07 20:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: gnu-emacs-bug '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). ^ permalink raw reply [flat|nested] 53+ messages in thread
[parent not found: <20131007203738.GA3099@acm.acm>]
* bug#15478: cc-mode does not obey electric-indent-mode [not found] ` <20131007203738.GA3099@acm.acm> @ 2013-10-07 23:08 ` Stefan Monnier 0 siblings, 0 replies; 53+ messages in thread From: Stefan Monnier @ 2013-10-07 23:08 UTC (permalink / raw) To: Alan Mackenzie; +Cc: gnu-emacs-bug >> 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-09-28 18:10 bug#15478: cc-mode does not obey electric-indent-mode Stefan Monnier ` (2 preceding siblings ...) 2013-10-05 17:06 ` Alan Mackenzie @ 2013-10-05 17:08 ` Alan Mackenzie 2014-02-17 19:02 ` Alan Mackenzie [not found] ` <20140217190249.GB4173@acm.acm> 5 siblings, 0 replies; 53+ messages in thread From: Alan Mackenzie @ 2013-10-05 17:08 UTC (permalink / raw) To: gnu-emacs-bug 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). ^ permalink raw reply [flat|nested] 53+ messages in thread
* bug#15478: cc-mode does not obey electric-indent-mode 2013-09-28 18:10 bug#15478: cc-mode does not obey electric-indent-mode Stefan Monnier ` (3 preceding siblings ...) 2013-10-05 17:08 ` Alan Mackenzie @ 2014-02-17 19:02 ` Alan Mackenzie [not found] ` <20140217190249.GB4173@acm.acm> 5 siblings, 0 replies; 53+ messages in thread From: Alan Mackenzie @ 2014-02-17 19:02 UTC (permalink / raw) To: 15478-done Enhancement done. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 53+ messages in thread
[parent not found: <20140217190249.GB4173@acm.acm>]
* bug#15478: cc-mode does not obey electric-indent-mode [not found] ` <20140217190249.GB4173@acm.acm> @ 2014-02-18 0:04 ` Stefan Monnier 0 siblings, 0 replies; 53+ messages in thread From: Stefan Monnier @ 2014-02-18 0:04 UTC (permalink / raw) To: 15478; +Cc: acm > Enhancement done. Thanks, Stefan ^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2014-02-18 0:04 UTC | newest] Thread overview: 53+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-09-28 18:10 bug#15478: cc-mode does not obey electric-indent-mode Stefan Monnier 2013-09-28 20:11 ` Alan Mackenzie 2013-09-29 3:02 ` Stefan Monnier 2013-09-29 9:10 ` Alan Mackenzie 2013-09-30 18:23 ` Stefan Monnier 2013-10-02 20:07 ` Alan Mackenzie 2013-10-03 1:50 ` Stefan Monnier 2013-10-03 2:46 ` Daniel Colascione 2013-10-03 4:10 ` Stefan Monnier 2013-10-03 4:13 ` Daniel Colascione 2013-10-03 4:50 ` Stefan Monnier 2013-10-03 5:56 ` Andreas Röhler 2013-10-03 6:31 ` Daniel Colascione 2013-10-03 15:52 ` Eli Zaretskii 2013-10-03 13:15 ` Dmitry Gutov 2013-10-03 15:04 ` Stefan Monnier 2013-10-03 17:40 ` Andreas Röhler 2013-10-03 9:45 ` Alan Mackenzie 2013-10-03 14:02 ` Stefan Monnier 2013-10-03 17:45 ` Andreas Röhler 2013-10-03 10:56 ` Alan Mackenzie 2013-10-03 14:32 ` Stefan Monnier 2013-10-04 21:21 ` Josh 2013-10-05 16:50 ` Alan Mackenzie 2013-10-06 17:45 ` Josh 2013-10-07 13:11 ` Alan Mackenzie 2013-10-07 21:23 ` Josh 2013-10-09 17:55 ` Alan Mackenzie 2013-10-03 11:54 ` Alan Mackenzie 2013-10-03 17:43 ` Andreas Röhler 2013-10-05 17:06 ` Alan Mackenzie 2013-10-06 1:10 ` Stefan Monnier 2013-10-06 2:55 ` Eli Zaretskii 2013-10-06 5:04 ` Josh 2013-10-07 9:39 ` Alan Mackenzie [not found] ` <20131007093859.GA3859@acm.acm> 2013-10-07 16:05 ` Eli Zaretskii 2013-10-07 21:17 ` Josh 2013-10-08 6:49 ` Eli Zaretskii 2013-10-08 15:59 ` Josh 2013-10-09 17:32 ` Alan Mackenzie [not found] ` <20131009173206.GA2610@acm.acm> 2013-10-10 19:11 ` Josh 2013-10-06 17:01 ` Stefan Monnier 2013-10-12 14:54 ` bug#15596: Let's improve the default workings of electric-indent-mode Alan Mackenzie 2013-10-12 16:35 ` Stefan Monnier 2013-10-13 12:36 ` Alan Mackenzie 2013-10-14 2:16 ` Stefan Monnier 2013-10-07 10:30 ` bug#15478: cc-mode does not obey electric-indent-mode Alan Mackenzie [not found] ` <20131007103041.GB3859@acm.acm> 2013-10-07 16:14 ` Stefan Monnier 2013-10-07 20:37 ` Alan Mackenzie [not found] ` <20131007203738.GA3099@acm.acm> 2013-10-07 23:08 ` Stefan Monnier 2013-10-05 17:08 ` Alan Mackenzie 2014-02-17 19:02 ` Alan Mackenzie [not found] ` <20140217190249.GB4173@acm.acm> 2014-02-18 0:04 ` Stefan Monnier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.