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

[Stefan <monnier@iro.umontreal.ca>]

>> 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 have no idea what you're talking about.  "electric-indent" to me
means "try to keep code indented without having to hit TAB".  In Elisp,
without electric-indent you have to use C-j or TAB if you want your
code indented.  So whether the user hits C-j or RET is relevant.

> Using electric indentation on RET is poor, because it only works when you
> actually type a RET (or a C-j).

That doesn't mean it's poor.  Just that it's not sufficient.
And I fully agree on this, which is why we have electric-indent-chars.

> 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.

Last I checked, RET is used more commonly than C-M-o.

> If you are typing in comments at the end of code lines, you won't want
> electric indentation messing up their alignment.

If auto-indentation gets it wrong, then indeed electric-indent will get
in the way.  That's true whether RET is electric or not.

> electric indentation is needed on keys other than RET; when that is the
> case, e-i on RET is superfluous.

Having RET in electric-indent-chars is not always indispensable, indeed.
But that doesn't make it harmful.  And of course, if you want, you can
remove it from electric-indent-chars either in your .emacs or in c-mode.

>> >> 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.

To me, the algorithm used by haskell-mode could not be used in
another context, so this distinction makes no sense.

> You've cut out the necessary context again, and put me to unnecessary
> work to restore it.

No, it's because the context did not manage to explain to me the text
that I quoted.  I stripped this context because it was not useful for me
to explain precisely which part I failed to understand.

> 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.

Thanks, yes, that makes sense.

> I put it to you, once more, that this "person-dependent" preference,
> as contrasted with a major-mode or buffer dependent one,
> is suboptimal.

What would be more optimal?

Clearly, having the major mode decide for the user is not better because
I can assure you that there are users who want electric indentation in
C-mode and there are others who don't.

> 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.

Well, mechanisms to do that were added at the same time as
electric-indent-mode.

But so it seems the part of the design you dislike in
electric-indent-mode is not the use of post-self-insert-hook (as
I assumed) but something else.  What is it?

It seems now that your main (only?) objection is having RET do
reindent-then-newline-and-indent instead of having it only do
newline-and-indent.  If that's the case, then let's focus on this.
In what scenario is it a problem?


        Stefan