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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Wed, Mar 19, 2014 at 09:46:03PM -0400, Stefan wrote:
> >> And the same holds true for all other programming modes.
> > No it doesn't.  We both agree that Emacs Lisp Mode has no use whatsoever
> > for electric indentation.

> No, I don't agree.  First because most people don't use C-j but use
> RET instead, and second because typing text linearly is far from being
> the only important editing pattern.

????  That's a non-sequitur.  The indentation of an elisp line of code is
solely dependent on the the lines before it - its indentation is
completely determined before any of its contents are typed in.  Therefore
there is nothing to be gained by reindenting this line at any subsequent
time, i.e. electric indentation.

Whether a user uses C-j or RET to terminate this line is irrelevant.

> > Then I suggest you think hard about the disadvantages of RET as an
> > electric indentation key.  If there weren't such disadvantages, CC Mode
> > would have been using it for 20 years.

> I need your help here, I'm afraid.  And I'm obviously not the only,
> because it's very common for text editors to "auto-indent on RET"
> (either by default, or via a config setting).

You're being vague, here.  By "auto-indent on RET" you could mean indent
the existing line ("electric indentation") or the new line created
("newline-and-indent").  The newline-and-indent behaviour is common in
other editors, electric indentation is not.  (I'm not aware of another
editor which does it, but I'm willing to be informed of any.)

Using electric indentation on RET is poor, because it only works when you
actually type a RET (or a C-j).  This is often not the case, e.g. when
you open up a line (e.g. with C-M-o) then type in a new line of code.

If you are typing in comments at the end of code lines, you won't want
electric indentation messing up their alignment.  You also want to know
how much space you've got between the comment opener and "column 80", for
whatever value of column 80 you use.  You will want electric indentation
to have done its thing _before_ you start typing the comment.  Thus
electric indentation is needed on keys other than RET; when that is the
case, e-i on RET is superfluous.

> >> There are details about *how* e-i-m works which depend on the mode.
> >> Yes.  That's why e-i-m has mode-local settings (e.g. which keys are
> >> electric, or whether the indentation algorithm can reliably reindent).
> > Any "indentation algorithm" can reliably reindent.  It is the context
> > in which the algorithm is used which is important, not the algorithm
> > itself.

> No: python-mode, haskell-mode, and coffeescript-mode can't.

We're in violent agreement, here.  It is the context (i.e. the major
mode) these indentation algorithms are used in, not the algorithms
themselves.  The algorithms themselves are perfectly capable of
reindentation.

> > Clearly.  I am pointing out that this definition is perhaps a suboptimal
> > one.

> I don't see what you mean by "definition" not "suboptimal".

You've cut out the necessary context again, and put me to unnecessary
work to restore it.  This makes it look like you want to evade answering
the point, without being obvious that this is what you are doing.  This
is one of the most irritating tactics that can be used on a mailing list,
short of out and out trolling.  PLEASE STOP DOING THIS!!!!

Here is that context, restored:
>>> But the global e-i-m setting is about deciding whether the user wants
>>> his code to be automatically indented as he types (to the extent
>>> possible).  It is *defined* as a person-dependent preference.

>>Clearly.  I am pointing out that this definition is perhaps a suboptimal
>>one.

> I don't see what you mean by "definition" not "suboptimal"

I think it's now clear which definition, your definition, we're talking
about.  I put it to you, once more, that this "person-dependent"
preference, as contrasted with a major-mode or buffer dependent one, is
suboptimal. 

> > Not even that.  You were in so much of a hurry to reinvent the wheel,
> > that you were oblivious of perfectly round wheels with smooth bearings
> > which had been in existence for ~20 years.

> No, I know those wheels very well, because I suffered through many of
> them.

Your "suffering", outlined below, concerned a peripheral annoyance, not
the basic design.  If that suffering was so great, how come you never
sent a report to bug-cc-mode about it?

The point is, that you could easily have taken over the design features
of CC Mode's electric indentation, which would likely have gone through
all sorts of false starts and design mistakes 20 years ago before
emerging with its well considered, slick design.  Instead, you started
from scratch, repeating history instead of learning from it.

> The problem is they're not modular: your rebinding of ?{ to make it
> auto-indent means that my global binding of ?{ to make it auto-pair
> doesn't work in c-mode.

You're saying it's OK for a _MINOR_ mode to bind "{" ???  This is crazy.
Supposing another minor mode also wanted to bind "{" for its purposes?
Which one wins?  This is clearly unsustainable.

Minor modes which want to hook up their functionality to a key like "{"
should do just that, not attempt to supersede other functionality.
Mechanisms for this exist - electric-indent-mode uses one of these, for
example.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).