emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC


From: Alan Mackenzie
Subject: Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.
Date: Sat, 22 Mar 2014 22:34:55 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hello, Stefan.

On Sat, Mar 22, 2014 at 12:14:54PM -0400, Stefan wrote:
> > 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".

The actual definition of "electricity" is found in the Emacs manual, page
"Electric C", where it has been for a very long time indeed.  It runs as
follows:

    In C mode and related modes, certain printing characters are
    "electric"--in addition to inserting themselves, they also reindent
    the current line, and optionally also insert newlines.

.  If you redefine the "electric" in "electric-indent" as you have done,
you conflate unrelated topics, and both your thought patterns and the
code end up a mess.  It is not helpful to construe `newline-and-indent'
as somehow being "electric".

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

No.  To keep Elisp properly indented, you merely have to depress
whichever key is bound to `newline-and-indent', whether that be RET, or
C-j, or whatever.  Electric indentation doesn't come into it.

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

Yes, but the point still stands.  You open up a fresh line, by RET, and
type code into it, but don't want to type RET/C-j at the end of it.
You'll want electric indentation on some other character you've just
typed.

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

No.  If electric indentation has already happened after typing the
semicolon/comma/brace, the alignment of the subsequent comment will
remain undisturbed.  If RET puts the alignment out, you're cursing it.

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

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

A mode-dependent or buffer-local dependent setting, as well as, rather
than instead of.

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

C Mode users who don't want electric indentation have been remarkably
quiet about it on bug-cc-mode, at least since `c-toggle-electric-state'
was introduced.

Each major mode should be able to decide on its own default, which the
user should be able to override easily.

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

Yes.

> 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 is the conflation of electric indentation with the "-and-indent" part
of `newline-and-indent', and the poor quality code this has led to.  For
example, `newline' and `newline-and-indent', strong, well understood,
well coded functions have been superseeded by new `newline' and
`electric-newline-and-maybe-indent', both vague functions which sometimes
indent the new line, sometimes don't.  Another example: `newline' has
been sullied with a grotesque new parameter "interactive" whose meaning
can not be reconciled with `newline''s functionality, but can only be
described by a flowchart of new `newline''s internal workings.

Having a minor mode tweek the global keymap on being enabled was
grotesque, but that has, thankfully, now been fixed.  The wierd
implementation of `electric-indent-local-mode', which didn't work
properly, is also getting fixed, though it is still needlessly
complicated.

I strongly dislike, even despise, the conflation of electric indentation
with the way (RET C-j) are bound to (`newline' `newline-and-indent').
The bindings of these keys has nothing to do with electric indentation,
and swapping their functionalities on {en,dis}abling e-i-m is bizarre.
There was no discussion of this on emacs-devel, and no consensus for this
change.  What _was_ discussed was the swapping of the two bindings in
programming modes, and it was coincidental that this discussion happened
in an offshoot of a thread discussing electric indentation mode.  Why
can't we simply have RET bound to `newline-and-indent' and C-j bound to
`newline' in programming modes, as discussed and, pretty much agreed on,
in emacs-devel last autumn?

Given that electric-indent-mode could have been implemented with the same
functionality in a clear, straightforward fashion, it is galling to see
the "clever", fragile, difficult to maintain code which we now have.

None of this am I saying here for the first time.

I object to the documentation of e-i-m on the info page "Convenience
Functions", as though it were some minor convenience function rather than
the essential component of automatic indentation it actually is.  But I
think we would agree this documentation needs amending anyway.

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

See above.  ;-)

> If that's the case, then let's focus on this.  In what scenario is it a
> problem?

I suppose it's not really a big problem.  Having RET/C-j as electric keys
in CC Mode just isn't needed.  _Any_ line of code in a real C/C++/...
program is going to contain some other electric character.  Other major
modes would likely also benefit from having characters other than RET
electric.

Incidentally, in Emacs -Q, Text Mode and Fundamental Mode have gone back
to the unwanted state of RET doing `newline-and-indent'.  Should I raise
another bug report?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]