Hello, João and Noam.
On Fri, May 10, 2019 at 23:12:06 -0400, Noam Postavsky wrote:
> Dima Kogan <dima@secretsauce.net> writes:
> > Hi.
> > I'm seeing a regression introduced in 2019/01 by an update meant to make
> > electric-pair-mode and electric-layout-mode play nicely:
> > http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=fd943124439b7644392919bca8bc2a77e6316d92
> > Recipe:
> > 1. 'emacs -Q' with any emacs more recent than that patch
> > 2. Open up tst.c that contains this:
> > int main(int argc, char* argv[])
> > {
> > return 0;
> > }
> > 3. Move the point to the beginning of the line containing "return 0"
> > 4. RET RET RET RET RET
> > Now there're a bunch of new lines between the { and the "return 0", as
> > expected. But these lines aren't empty: they contain the initial
> > indentation whitespace. This whitespace shouldn't be there; and it
> > wasn't there prior to this patch.
> 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. Possibly c-mode should rebind RET to a
> c-electric-return command or something.
> >>From 1103fdfbf2be55d68d44151498c2598fd622ac08 Mon Sep 17 00:00:00 2001
> From: Noam Postavsky <npostavs@gmail.com>
> Date: Fri, 10 May 2019 16:40:27 -0400
> Subject: [PATCH] Inhibit electric indent completely in cc mode buffers
> (Bug#35254)
> 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.
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)?
2. Do any of you have suspicions that it might introduce problems elsewhere?
3. Does it pass the automated test suite?
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. 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.
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