bug#35254: 27.0.50; cc-mode/electric-pair-mode/electric-layout-mode: bad trailing whitespace behavior in cc-mode

[Alan Mackenzie]

Hello, João.

On Mon, May 13, 2019 at 23:39:33 +0100, João Távora wrote:
> On Mon, May 13, 2019 at 8:53 PM Alan Mackenzie <acm@muc.de> wrote:

[ .... ]

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

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

> > I interpret the problem a little differently.
> > electric-indent-post-self-insert-function, when electric-indent-inhibit
> > is set, is inhibiting actions which are not really part of electric
> > indentation, in particular action 2 (above).  This is the heart of the
> > bug.  The following patch fixes the bug.  It would need tidying up before
> > being committed:



> > diff --git a/lisp/electric.el b/lisp/electric.el
> > index 07da2f1d9e..15a42930c1 100644
> > --- a/lisp/electric.el
> > +++ b/lisp/electric.el
> > @@ -282,9 +282,15 @@ electric-indent-post-self-insert-function
> >                    (condition-case-unless-debug ()
> >                        (indent-according-to-mode)
> >                      (error (throw 'indent-error nil)))
> > -                  ;; The goal here will be to remove the trailing
> > -                  ;; whitespace after reindentation of the previous line
> > -                  ;; because that may have (re)introduced it.
> > +                  )
> > +                (unless (memq indent-line-function
> > +                              electric-indent-functions-without-reindent)
> > +                  ;; The goal here will be to remove the indentation
> > +                  ;; whitespace from an otherwise blank line after
> > +                  ;; typing <CR> twice in succession.  Also to remove
> > +                  ;; trailing whitespace after reindentation of the
> > +                  ;; previous line because that may have
> > +                  ;; (re)introduced it.
> >                    (goto-char before)
> >                    ;; We were at EOL in marker `before' before the call
> >                    ;; to `indent-according-to-mode' but after we may


> > João and Noam, what're your views on this proposed patch?

> > Good night Alan,

> Unfortunately, I can't analyse this in depth right now or in the next
> few days.

As Stefan(?) said, there's no particular hurry (on a scale of days) to
fix this.

> I can only ask succintly:

> 1. Does it fix the reported problem (assuming it is a problem, and not an
> otherwise potentially desirable change in behaviour)?

It does fix it, yes.  It was a bug.

> 2. Do any of you have suspicions that it might introduce problems
> elsewhere?

I don't, as such, but I haven't dug around the code looking for potential
problems.  That was the main reason I was asking you, as maintainer of
the electric stuff.

> 3. Does it pass the automated test suite?

Noam has already tried this and said it fails on three tests.

> I am only a bit wary of it because, without having understood the
> problem in depth, it seems again caused by a c-electric quirk.

The same bug occurs in Python Mode.

Succinctly, the bug is that on pressing <CR> lots of times in a row, the
indentation WS is being left on the blank lines rather than being
removed.

> My views on this are known: I always prefer that c-mode would, if
> slowly, move in the direction of accepting electric.el abstractions as
> closely as possible.

I think we've already agreed that CC Mode should, in the long term,
change to using the electric-* facilities, assuming no loss in
functionality.  :-)

> Than said, the patch looks very simple, which is always good, and has
> comments explaining what's going on. So I'll let Noam (and Stefan?) decide.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).