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