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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Thu, Mar 27, 2014 at 10:49:06AM -0400, Stefan Monnier wrote:
> >> I want to keep electric-indent-mode as a global mode that determines
> >> whether certain self-inserting keys (such as RET and others) auto-indent.
> > How is this not satisfied by e-i-m being a define-globalized-minor-mode?

> AFAICT your suggestion would not swap RET/C-j depending on e-i-m.

It would most emphatically not do so.  That is something which was never
discussed on emacs-devel before it was implemented, and it is wrong.
Unrelated things should not be bound together into a single action.

> > With the current setup, we have a rather contorted relationship between
> > e-i-m and e-i-local-m, with buffer local copies of electric-indent-mode
> > popping into and out of existence.

> For a setting which is mostly global by nature (it reflects on the
> user's general preference), I'm not worried and generally prefer this
> over using define-globalized-minor-mode which is a fine hack, but
> a hack nevertheless.

Eh?  How does global-font-lock-mode, for example, not work 100%?  It is
also "mostly global by nature".  What might not work properly if e-i-m
was made into a globalized minor mode?

With a globalized-minor-mode, it is predictable which buffers are
affected when the global command is given, namely all of them.  With
e-i-m, only some buffers are affected, and there is currently no
rationale behind which ones are, which ones aren't.  You need to read the
source code to work this out, and that is bad.

> > What about the rest of my suggestion?

> I'm worried about the possible consequences: e-i-m has been around for
> a little while now and we're somewhat familiar with its problems.

The changes I'm proposing, with the exception already noted, are not
changes in functionality.  e-i-m is essentially still fresh code - one or
two enthusiasts used it in 24.3, but it hasn't really hit big time yet.
Now is the right time to sort out its problems.  Besides, we're hackers,
and we're competent.  :-)

> Your approach might solve some problems (tho I haven't seen a clear
> statement of what those problems are, in terms of *behavior*), ...

e-i-m also toggling RET/C-j is a behaviour problem, as noted above.

But the other problems are those of bad design and bad coding, not bad
behaviour.  They are all the the consequence of a single design mistake,
namely that e-i-post-self-insert-function tries to handle the indentation
of a new line.  This has led to difficult to understand overcomplicated
coding, functional duplication, disassociation of functionality from
defuns, damaged backward compatibility, ....

These problems should be _fixed_.  To fix them is not difficult.  I'm
willing to do this.

> .... but will inevitably come with its own set of consequences.

Inevitably?  How so?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).