[Top][All Lists]

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

bug#35254: 27.0.50; cc-mode/electric-pair-mode/electric-layout-mode: bad

From: Alan Mackenzie
Subject: bug#35254: 27.0.50; cc-mode/electric-pair-mode/electric-layout-mode: bad trailing whitespace behavior in cc-mode
Date: Sat, 11 May 2019 16:19:03 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, Noam.

On Sat, May 11, 2019 at 10:06:42 -0400, Noam Postavsky wrote:
> Alan Mackenzie <address@hidden> writes:

> [rearranged a bit for better flow]


> >> Right, the problem is that electric-indent-inhibit only partially
> >> disables electric indent, and the commit you reference changes which
> >> parts.  The patch below disables it more completely.  Note however, that
> >> this makes RET not do any electric indentation at all, just like in the
> >> good old days of Emacs 24.3.

> >> Subject: [PATCH] Inhibit electric indent completely in cc mode buffers

> >> Electric indent mode's post-self-insert hook entry has 3 effects:

> >> 1. Indent the previous line.
> >> 2. Remove trailing whitespace from the previous line.
> >> 3. Indent the current line (when at beginning of line).

> > I don't quite agree with this.  The problem is confusion between effect
> > 2 [above] and electric indentation.  This effect 2 is fundamental editor
> > functionality, and should be independent, MUST be independent of anything
> > called "electric indentation".  The two things are conceptually
> > unrelated.

> So we should have an electric-delete-trailing-whitespace-mode?

NO, NO, NO, NO, NO, NO, NO!!!!

Again, the cause of the current problem is that the deletion of the
trailing WS has got mixed up with electric stuff.  General confusion.

Trailing WS deletion has got NOTHING to do with electric indentation.  It
was part of `newline-and-indent' long before anybody started trying to
apply CC Mode's electric stuff to other modes.  It should be part of
`newline' now, not part of electric-indent-post-self-insert-function.

> >> The change from 2019-01-22 "electric-layout-mode kicks in before
> >> electric-pair-mode", makes 'electric-indent-inhibit' inhibit 1 and 2,
> >> whereas before then it inhibited only 1.  While cc mode provides its
> >> own electric commands and therefore sets 'electric-indent-inhibit', it
> >> doesn't implement an electric newline command.  So if only one of
> >> effects 2 and 3 from Electric indent mode occur, then hitting RET will
> >> leave trailing whitespace.

> >> * lisp/progmodes/cc-mode.el (c-electric-indent-mode-function): New
> >> function.
> >> (c-basic-common-init): Add it to electric-indent-functions to disable
> >> electric indent completely (while still letting the
> >> electric-indent-mode command/setting to control c-electric-flag as
> >> before).

> >>    (when (boundp 'electric-indent-inhibit) (setq electric-indent-inhibit 
> >> t))
> >> +  (add-hook 'electric-indent-functions 'c-electric-indent-mode-function 
> >> nil t)

> >> +(defun c-electric-indent-mode-function (char)
> >> +  ;; We never want `electric-indent-mode' to do anything.
> >> +  'no-indent)

> > I'm against this patch.  It is an unpleasant workaround in CC Mode for
> > problems in the Emacs core.  CC Mode has set electric-indent-inhibit to
> > t, and the Emacs core should respect that setting.  Using
> > electric-indent-functions in the way suggested couples CC Mode
> > undesirably with electric indentation, possibly leading to future
> > problems when electric indentation gets changed in the future.

> Hmm, from my point of view, the whole point of the patch is to
> *UNcouple* CC mode from electric.el's electric indentation (since CC
> mode has its own electric functionality), something that
> electric-indent-inhibit does only partially (and based on your response
> above I guess the reason for being partial is that there is some
> disagreement over which parts exactly constitute "electric
> indentation").

This further incursion of electric- stuff into CC Mode is an inevitable
consequence of the confusion described above.  Again, setting a single
flag saying NO! should be enough, without having to configure the
mechanisms which are supposedly disabled.

> >> Possibly c-mode should rebind RET to a c-electric-return command or
> >> something.

> > CC Mode should be able to rely on the proper working of basic editor
> > functionality.  It shouldn't have to implement its own version of
> > `newline'.

> > In previous Emacs versions (?23.x, ?24.x) there were two simple commands
> > `newline' and `newline-and-indent'.  As far as I remember, they both
> > removed trailing WS from the "old" line, possibly as part of the filling
> > which was done.  They worked, and worked well.  Why can't we get this
> > functionality back again?

> Both these commands still exist.  As far as I can tell, `newline' never
> removed trailing WS.

I think you're right.  It might even have been an annoyance at the time.
Personally I always used `newline-and-indent', bound to C-j.

> It does have some code to delete the "left margin", but that doesn't
> seem to be intended for programming modes where the margin is 0
> (disabled).

> `newline-and-indent' did, and still does, delete trailing whitespace.
> In 24.4, C-j was rebound from `newline-and-indent' to
> `electric-newline-and-maybe-indent' which only calls
> `newline-and-indent' if `electric-indent-mode' is nil.

Yes.  The ability simply to switch over the two keys between `newline'
and `newline-and-indent' by an option was confused into
electric-indent-mode, something I protested strongly against at the time.
My objections were not addressed, they were simply evaded and brushed

> Of course c-mode could rebind it in its mode map (I considered making
> `electric-newline-and-maybe-indent' consult `electric-indent-functions'
> as well but that won't work because that hook is supposed to run after
> the character is inserted).

I think we've got enough foggy complexity in the area as it is.  I
suppose CC Mode could bind <CR> to `newline-and-indent', but there's now
no longer a clean function which does what `newline' used to do, to bind
onto C-j.

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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