Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hi, Stefan.

On Sun, Mar 09, 2014 at 11:37:36PM -0400, Stefan Monnier wrote:

> >> What is essential for me is that C-mode have the same behavior as other
> >> modes.  I.e. obey electric-indent-mode.
> > Major modes provide different behaviours, behaviours appropriate to the
> > type of text being edited.  That's why we have major modes.

> Right.  But I don't see what is so special about the C language that
> makes c-electric-flag (aka electric-indent-mode) indispensable in c-mode.

CC Mode modes don't indent correctly automatically without electric
indentation.  This is in the typical case where lines of code are being
typed in, line by line.

> Better don't bother answering: electric-indent-mode is enabled by
> default anyway, so there's really no problem here.

Good!

> The question is really: why do you need to know if electric-indent-mode
> was called (and even how many times)?  From what I understand of your
> previous answers it is because you want to only obey
> electric-indent-mode if the user changed the default.

Not quite.  I want the default for CC Mode modes to be t, regardless of
any system wide default.  I think it likely there will be other major
modes which need a default of nil.  Once a user has positively indicated
which way she wants the setting, then that is fine.

> If so, what is wrong about testing Emacs's version instead?

????

> AFAIK your only worry is when electric-indent-mode is nil to make sure
> that the user really meant it.  But if you test Emacs's version to make
> sure it's >24.3, then electric-indent-mode can only be nil if the user
> decided so.

electric-indent-mode is, essentially, new code, and its default doesn't
appear yet to have stabilised.  As I've already said, I anticipate a
storm of protest and a sea of confusion over this new default.  In order
to quell the protest, there will be the option of making the default nil
in future versions.  It would be good to have CC Mode decoupled from
this.

> So you don't need to know if electric-indent-mode has been called nor
> how many times.


>         Stefan


> > > No, we should only care about "enabled" and "disabled".
> > That's a fairly contentious opinion, not backed up by any reasoning.
> > Would you care to give your reasons why "default state" is not to be
> > cared about?

> You know very well:
> some major modes have historically setup some keys to electrically
> reindent the current line.  And some haven't.  This just reflects
> the personal preference of the major mode's author(s).

No.  It reflects the intrinsic needs of the major mode.  CC Mode needs
it, Emacs Lisp Mode is never going to have a use for it, Text Mode needs
it nil, and in some modes, electric indentation plain doesn't work
(python, for example).

> It also means that a user who doesn't like this behavior needs to
> disable it separately for each and every such major mode (which
> includes figuring out how to disable it, which is not standardized
> either).  And it also means that a user who does like this behavior
> will have to tweak the other major modes.

I think you are wrong in your tacit assumption that liking of e-i-m is
person dependent rather than major mode dependent.

> Hence my introducing electric-indent-mode to standardize the behavior
> across modes.  As is too often the case, CC-mode is the only one that
> doesn't want to get in line.

The way electric-indent-mode was implemented seems optimised to maximise
the difficulty of integrating CC Mode with it.  My main concern over this
integration has been avoiding loss of or damage to functionality.  CC
Mode's electric indentation is essentially 100% perfect, all the rough
edges and conflicts having been debated and settled in long forgotten 20
year old exchanges.  Have you ever wondered why RET and C-j aren't
electric keys in CC Mode?

Compatibility with stand-alone CC Mode has also been of some concern.

> > As we have discussed before, it is essential that c-electric-flag be
> > enabled by default for CC Mode buffers.  Without it, indentation would
> > need to be done manually, e.g. by continual use of the tab key.

> Right: when electric-indent-mode is nil, it means that the user wants to
> have control over when auto-indentation is performed.  That's not a bug.

This is the case after e-i-m has been SET to nil.  What is a bug (IMNSHO)
is that this selection is not buffer local.  Other similar features are
implemented as buffer local with a "global-*" variant: font-lock-mode,
hi-lock-mode, .....  There are at least 17 such minor modes with a global
variant.  electric-indent-mode is going to be inconsistent with these
other modes.  Why couldn't we have had electric-indent-mode and
global-electric-indent-mode?

> On the contrary: it is crucial to stay sane when you're editing code
> using an indentation convention that's different from the one supported
> by the major mode.

That is indeed the use case for no electric indentation (with the lesser
one of newbies who can't yet cope with it).

> But indeed, electric-indent-mode is enabled by default, because we
> recognize that it is overall better to try and maintain indentation
> without forcing the user to constantly use TAB.

Yes.

> > Yet c-electric-flag, a buffer local flag, is now inextricably coupled
> > to electric-indent-mode, a crude global flag.  A user wishing to
> > disable electric-indent-mode for some random buffer will find
> > automatic indentation broken in her C Mode buffers.

> No, she will find it correctly disabled, according to her wish expressed
> by the fact that she disabled electric-indent-mode.

You're assuming here that she will be disabling e-i-m due to a general
dislike of electricity, rather than having an isolated chaotically indented
buffer.

> > There is no mechanism provided to users by electric-indent-mode to enable
> > it selectively in a buffer.

> Alan, please be constructive: you know full well this is untrue.

> > Even the undocumented electric-indent-local-mode

> The fact that it's not yet documented is irrelevant, since that's
> a problem that needs to be addressed anyway (and rather sooner than
> later since it's one of the hurdles remaining for the trunk to re-open).

:-)

> > doesn't work properly, as you admitted recently.

> Right, it has some bugs open, and we'll have to fix them for 24.4.

Double :-).  On 2014-02-18 you opined "I don't think it's worth the
trouble" to fix.  I feel relieved it will be getting fixed now.

> > In the massive confusion and possible protest that will follow in the
> > wake of the release of electric-indent-mode, one of your options will be
> > to disable the mode by default.

> Come on, Alan.  You know me better than that.

> And FWIW you've been the strongest voice *against* enabling
> electric-indent-mode, oddly enough.

I don't think so.  I have strongly objected to the design features of
electric-indent-mode and protested against the collateral effects they
have on the rest of Emacs.

> > Would you please give your word, as a gentleman, that whatever
> > transpires, after the sequence emacs -Q, C-x C-f foo.c, foo.c's copy
> > of c-electric-flag will always be t.

> No, I can't, sorry: if it were up to me, c-electric-flag would not even
> exist any more.

Yes, I'm sure.  The flag is needed for all Emacsen which aren't GNU Emacs
24.4+.  It is well tested, works, seems to be used, and has never
elicited complaints from users.

> But I can give you my word that "automatic indentation as a side effect
> of normal editing" will be enabled by default in programming modes,
> including C-like modes, yes.

Thanks.  That will do.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).