From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 15596@debbugs.gnu.org
Subject: bug#15596: Let's improve the default workings of electric-indent-mode.
Date: Sun, 13 Oct 2013 12:36:59 +0000 [thread overview]
Message-ID: <20131013123659.GB2621@acm.acm> (raw)
In-Reply-To: <jwv61t2sbjc.fsf-monnier+emacsbugs@gnu.org>
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).
next prev parent reply other threads:[~2013-10-13 12:36 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-28 18:10 bug#15478: cc-mode does not obey electric-indent-mode Stefan Monnier
2013-09-28 20:11 ` Alan Mackenzie
2013-09-29 3:02 ` Stefan Monnier
2013-09-29 9:10 ` Alan Mackenzie
2013-09-30 18:23 ` Stefan Monnier
2013-10-02 20:07 ` Alan Mackenzie
2013-10-03 1:50 ` Stefan Monnier
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 [this message]
2013-10-14 2:16 ` Stefan Monnier
2013-10-07 10:30 ` bug#15478: cc-mode does not obey electric-indent-mode Alan Mackenzie
[not found] ` <20131007103041.GB3859@acm.acm>
2013-10-07 16:14 ` Stefan Monnier
2013-10-07 20:37 ` Alan Mackenzie
[not found] ` <20131007203738.GA3099@acm.acm>
2013-10-07 23:08 ` Stefan Monnier
2013-10-05 17:08 ` Alan Mackenzie
2014-02-17 19:02 ` Alan Mackenzie
[not found] ` <20140217190249.GB4173@acm.acm>
2014-02-18 0:04 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131013123659.GB2621@acm.acm \
--to=acm@muc.de \
--cc=15596@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.