Well,

I've just come across the bug myself, and it is indeed annoying.
Can you check if this patch, which seems the simplest, serves
all purposes? It also adds a test to prevent future regressions

Thanks,
João

diff --git a/lisp/electric.el b/lisp/electric.el
index 657913a396..f15a95bf91 100644
--- a/lisp/electric.el
+++ b/lisp/electric.el
@@ -281,10 +281,13 @@ electric-indent-post-self-insert-function
                   (goto-char before)
                   (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.
+                    (error (throw 'indent-error nil))))
+                (unless (eq electric-indent-inhibit 'electric-layout-mode)
+                  ;; Unless we're operating under
+                  ;; `electric-layout-mode' (Bug#35254), the goal here
+                  ;; will be to remove the 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
@@ -464,7 +467,7 @@ electric-layout-post-self-insert-function-1
                       ;; really wants to reindent, then
                       ;; `last-command-event' should be in
                       ;; `electric-indent-chars'.
-                      (let ((electric-indent-inhibit t))
+                      (let ((electric-indent-inhibit 'electric-layout-mode))
                         (funcall nl-after)))))))
             (pcase sym
               ('before (funcall nl-before))
diff --git a/test/lisp/electric-tests.el b/test/lisp/electric-tests.el
index 4f1e5729be..22b7a18ba5 100644
--- a/test/lisp/electric-tests.el
+++ b/test/lisp/electric-tests.el
@@ -876,6 +876,24 @@ electric-layout-for-c-style-du-jour
       (call-interactively (key-binding `[,last-command-event])))
     (should (equal (buffer-string) "int main () {\n  \n}"))))
 
+(ert-deftest electric-layout-control-reindentation ()
+  "Same as `e-l-int-main-kernel-style', but checking Bug#35254."
+  (ert-with-test-buffer ()
+    (plainer-c-mode)
+    (electric-layout-local-mode 1)
+    (electric-pair-local-mode 1)
+    (electric-indent-local-mode 1)
+    (setq-local electric-layout-rules
+                '((?\{ . (after))
+                  (?\} . (before))))
+    (insert "int main () ")
+    (let ((last-command-event ?\{))
+      (call-interactively (key-binding `[,last-command-event])))
+    (should (equal (buffer-string) "int main () {\n  \n}"))
+    ;; insert an additional newline and check indentation
+    (call-interactively 'newline)
+    (should (equal (buffer-string) "int main () {\n\n  \n}"))))
+
 (define-derived-mode plainer-c-mode c-mode "pC"
   "A plainer/saner C-mode with no internal electric machinery."
   (c-toggle-electric-state -1)




On Wed, May 15, 2019 at 11:03 AM Alan Mackenzie <acm@muc.de> wrote:
Hello, João.

On Tue, May 14, 2019 at 11:34:24 +0100, João Távora wrote:
> On Tue, May 14, 2019 at 10:27 AM Alan Mackenzie <acm@muc.de> wrote:

> > The bug is, type lots of <CR>s in a row; the indentation WS isn't
> > getting removed from the blank lines.  Currently electric-indent-inhibit
> > is inhibiting this removal.


> Do you mean the "removal of the WS in the lines preceding the current".
> In other words, do you mean "removal of the trailing WS that was once
> proper indentation"?

Yes.  To be absolutely clear, supposing we have point at the end of a
line containing nothing but indentation space (e.g., we've just typed
<CR>):

<spaces>!
        ^
      point

Type <CR> again.  What we are currently seeing is:

<spaces>
<spaces>!

.  What we want to see is

<nothing>
<spaces>!

.

> Or do you think that the current line, the one where point stands, should
> not be indented at all in certain electric-* variable combinations and or
> c-electric-* variable?  Which of those combinations?

When electric-indent-inhibit is set, the (electric) indentation of the
current line should not be done by electric-indent-mode.  For the
moment, in CC Mode it should be done by c-electric-brace, and friends,
if so configured in CC Mode (the default being enabled).

> > Probably.  Maybe João should check this, once he's fully back with us.


> I'm afraid I can't put a date on that. There's a bun in the oven...

Well, congratulations!  I hope everything goes well.

> An important development towards figuring out this issue is that a
> significant fraction of us agrees on what the behavior should be
> in what cases.  Then we should code tests that assert that behavior
> possibly reusing the fixtures in electric-tests.el.

Yes.

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

> I see.  That does make sense. But, to be sure, we _dont_ what to
> remove the indentation WS on the "current" line, right?

Right.  Unless, and until, the current line becomes the "previous" line,
still otherwise being blank.

I think we're agreed on everything.  :-)

> João

--
Alan Mackenzie (Nuremberg, Germany).


--
João Távora