From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#35254: 27.0.50; cc-mode/electric-pair-mode/electric-layout-mode: bad trailing whitespace behavior in cc-mode Date: Mon, 13 May 2019 23:39:33 +0100 Message-ID: References: <87ftqms9db.fsf@secretsauce.net> <871s15k7ll.fsf@gmail.com> <20190513195323.GB5525@ACM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d57f7a0588cc97a3" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="19975"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Noam Postavsky , 35254@debbugs.gnu.org, Dima Kogan To: Alan Mackenzie , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 14 00:40:41 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hQJce-00054Z-GH for geb-bug-gnu-emacs@m.gmane.org; Tue, 14 May 2019 00:40:40 +0200 Original-Received: from localhost ([127.0.0.1]:35977 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQJcd-0004G5-Gq for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 May 2019 18:40:39 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55705) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQJcT-0004FV-Ts for bug-gnu-emacs@gnu.org; Mon, 13 May 2019 18:40:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQJcR-0000Y0-HD for bug-gnu-emacs@gnu.org; Mon, 13 May 2019 18:40:29 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33018) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hQJc4-0000HS-M8; Mon, 13 May 2019 18:40:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hQJc2-00018I-7f; Mon, 13 May 2019 18:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Mon, 13 May 2019 22:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35254 X-GNU-PR-Package: emacs,cc-mode Original-Received: via spool by 35254-submit@debbugs.gnu.org id=B35254.15577871954335 (code B ref 35254); Mon, 13 May 2019 22:40:02 +0000 Original-Received: (at 35254) by debbugs.gnu.org; 13 May 2019 22:39:55 +0000 Original-Received: from localhost ([127.0.0.1]:46562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hQJbu-00017q-C2 for submit@debbugs.gnu.org; Mon, 13 May 2019 18:39:54 -0400 Original-Received: from mail-it1-f196.google.com ([209.85.166.196]:55622) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hQJbr-00017c-H9 for 35254@debbugs.gnu.org; Mon, 13 May 2019 18:39:52 -0400 Original-Received: by mail-it1-f196.google.com with SMTP id q132so1808223itc.5 for <35254@debbugs.gnu.org>; Mon, 13 May 2019 15:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W9ge8Bz0V0r/RU4E3TaRpFWJ76vQq5mIxwAOeh0TVd8=; b=TXTnigfAXGT6AIiHkJi3YbPXjJY+QjDIdLR/qtz75MdxTOXZE4V4d1if83JnQIXwLk tP9l3pQqQo3XQAEQPr06cXfSfwsejnzjaaD1vTYQnhgvr/O7wLhFwu4tyf7qCpX0OESn Q09h7q0GaxMgcBlLihwo2gYlDJbMH+gK7Lr1cmKW397EFFO6MkQfJHCbu7WSZIoSksMK o1AFcQHQGMRX8VYVCQGVkw++C524RqSfbyUN4EB65QP2nnFbZGC2GQQvBd5oQ2fdEs93 s86uu+sR60SXVtHy0Af7/iqviZ2R6KI2OyWNnIflc+l2hE9+AL8a1tqzs0s1usjF6Esd nmjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W9ge8Bz0V0r/RU4E3TaRpFWJ76vQq5mIxwAOeh0TVd8=; b=fyzpruy4o9YmwRkovanmZZiCDKkvhwB40MFpEj1lW/dlIEY8ZH0bUZiLKC/E772FFU yoxQkQrCi/t5ZKP3rZcdCtE2nRF1fuhEpo6XNMht+B68w1Cay8AENgyGTNzLahog2pEr 3kGLnnYkQmrphlYFW2i9/SiUhl31+yuvGCxsTs7UQYdEIPFWRoCP/kyrLjmnDJ0S03pc b5oAUN7DI2NMUSNFgIawjNapZOft630Kyk4uJ7dXsi56j7BXL1E20fZSnXkVROlVN1o3 bvnUMIGiK8/w8jTKEsXJzgX6J1DPoGuA7A/iMmFJvM5wAMitXnZrw+nW/CYoq8H/EtxJ TJYQ== X-Gm-Message-State: APjAAAVytx4+qbsbR+r2LkNdpdEsNngHk9rLce3yWANfA7/OdqvRjNPK 3O/z11PIWFjRpeDim/sxbY0klRh9+AQqhc2DmKc= X-Google-Smtp-Source: APXvYqyMWlBztKEe49atwckzd2O+YcIvyE75F5ikNMgsLmUTw5+SSDjlTtU0DMZ/MDGAfFybAlC/rVRyWabA5tWOEK8= X-Received: by 2002:a02:80e:: with SMTP id 14mr20494144jac.71.1557787185609; Mon, 13 May 2019 15:39:45 -0700 (PDT) In-Reply-To: <20190513195323.GB5525@ACM> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:159227 Archived-At: --000000000000d57f7a0588cc97a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 13, 2019 at 8:53 PM Alan Mackenzie wrote: > Hello, Jo=C3=A3o and Noam. > > On Fri, May 10, 2019 at 23:12:06 -0400, Noam Postavsky wrote: > > Dima Kogan 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=3Dfd943124439b76443= 92919bca8bc2a77e6316d92 > > > > 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", a= s > > > 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, tha= t > > 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 200= 1 > > From: Noam Postavsky > > 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 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=C3=A3o 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=C3=A3o --000000000000d57f7a0588cc97a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 13, 2019 at 8:53 PM Alan Mack= enzie <acm@muc.de> wrote:
=
dima@secretsauce.net> writes:

> > Hi.

> > I'm seeing a regression introduced in 2019/01 by an update me= ant to make
> > electric-pair-mode and electric-layout-mode play nicely:

> >=C2=A0 =C2=A0http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3Df= d943124439b7644392919bca8bc2a77e6316d92

> > Recipe:

> > 1. 'emacs -Q' with any emacs more recent than that patch<= br>
> > 2. Open up tst.c that contains this:

> > int main(int argc, char* argv[])
> > {
> >=C2=A0 =C2=A0 =C2=A0return 0;
> > }


> > 3. Move the point to the beginning of the line containing "r= eturn 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 init= ial
> > indentation whitespace. This whitespace shouldn't be there; a= nd 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.=C2=A0 The patch below disables it more completely.=C2=A0 Note h= owever, that
> this makes RET not do any electric indentation at all, just like in th= e
> good old days of Emacs 24.3.=C2=A0 Possibly c-mode should rebind RET t= o 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=
>=C2=A0 (Bug#35254)

> Electric indent mode's post-self-insert hook entry has 3 effects:<= br>
> 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<= br> > electric-pair-mode", makes 'electric-indent-inhibit' inhi= bit 1 and 2,
> whereas before then it inhibited only 1.=C2=A0 While cc mode provides = its
> own electric commands and therefore sets 'electric-indent-inhibit&= #39;, it
> doesn't implement an electric newline command.=C2=A0 So if only on= e 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).=C2=A0 This is the heart of the=
bug.=C2=A0 The following patch fixes the bug.=C2=A0 It would need tidying u= p 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
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(condi= tion-case-unless-debug ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0(indent-according-to-mode)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(error (throw 'indent-error nil)))
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; The goal= here will be to remove the trailing
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; whitespa= ce after reindentation of the previous line
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; because = that may have (re)introduced it.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 )
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (unless (memq inde= nt-line-function
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 electric-indent-functions-without-reindent)=
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; The goal= here will be to remove the indentation
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; whitespa= ce from an otherwise blank line after
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; typing &= lt;CR> twice in succession.=C2=A0 Also to remove
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; trailing= whitespace after reindentation of the
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; previous= line because that may have
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; (re)intr= oduced it.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(goto-= char before)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; We = were at EOL in marker `before' before the call
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; to = `indent-according-to-mode' but after we may


Jo=C3=A3o and Noam, what're your views on this proposed patch?

<= /blockquote>
Good night Alan,

Unfortunatel= y, 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 rep= orted problem (assuming it is a problem, and not an otherwise
=C2=A0=C2=A0 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 a= m only a bit wary of it because, without having understood the problem in d= epth,
it seems again caused by a c-electric quirk. My views on th= is are known: I always prefer
that c-mode would, if slowly, = move in the direction of accepting electric.el abstractions as
cl= osely as possible.

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

Jo=C3=A3o
<= /div> --000000000000d57f7a0588cc97a3--