unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Noam Postavsky <npostavs@gmail.com>
Cc: "Dima Kogan" <dima@secretsauce.net>,
	35254@debbugs.gnu.org, "João Távora" <joaotavora@gmail.com>
Subject: bug#35254: 27.0.50; cc-mode/electric-pair-mode/electric-layout-mode: bad trailing whitespace behavior in cc-mode
Date: Sat, 11 May 2019 12:05:24 +0000	[thread overview]
Message-ID: <20190511120524.GA15991__9936.80583066947$1557576394$gmane$org@ACM> (raw)
In-Reply-To: <871s15k7ll.fsf@gmail.com>

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

I don't quite agree with this.  The problem is confusion between effect
2 (below) and electric indentation.  This effect 2 is fundamental editor
functionality, and should be independent, MUST be independent of anything
called "electric indentation".  The two things are conceptually
unrelated.

> Possibly c-mode should rebind RET to a c-electric-return command or
> something.

CC Mode should be able to rely on the proper working of basic editor
functionality.  It shouldn't have to implement its own version of
`newline'.

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

> * lisp/progmodes/cc-mode.el (c-electric-indent-mode-function): New
> function.
> (c-basic-common-init): Add it to electric-indent-functions to disable
> electric indent completely (while still letting the
> electric-indent-mode command/setting to control c-electric-flag as
> before).
> ---
>  lisp/progmodes/cc-mode.el | 5 +++++
>  1 file changed, 5 insertions(+)

> diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
> index bd62fc754a..e41f1101d0 100644
> --- a/lisp/progmodes/cc-mode.el
> +++ b/lisp/progmodes/cc-mode.el
> @@ -634,6 +634,7 @@ (defun c-basic-common-init (mode default-style)
>    ;; messing up CC Mode's, and set `c-electric-flag' if `electric-indent-mode'
>    ;; has been called by the user.
>    (when (boundp 'electric-indent-inhibit) (setq electric-indent-inhibit t))
> +  (add-hook 'electric-indent-functions 'c-electric-indent-mode-function nil t)
>    ;; CC-mode should obey Emacs's generic preferences, tho only do it if
>    ;; Emacs's generic preferences can be set per-buffer (Emacs>=24.4).
>    (when (fboundp 'electric-indent-local-mode)
> @@ -2143,6 +2144,10 @@ (defun c-electric-indent-local-mode-hook ()
>      (setq c-electric-flag electric-indent-mode)
>      (c-update-modeline)))

> +(defun c-electric-indent-mode-function (char)
> +  ;; We never want `electric-indent-mode' to do anything.
> +  'no-indent)
> +
>  \f
>  ;; Support for C

I'm against this patch.  It is an unpleasant workaround in CC Mode for
problems in the Emacs core.  CC Mode has set electric-indent-inhibit to
t, and the Emacs core should respect that setting.  Using
electric-indent-functions in the way suggested couples CC Mode
undesirably with electric indentation, possibly leading to future
problems when electric indentation gets changed in the future.

In previous Emacs versions (?23.x, ?24.x) there were two simple commands
`newline' and `newline-and-indent'.  As far as I remember, they both
removed trailing WS from the "old" line, possibly as part of the filling
which was done.  They worked, and worked well.  Why can't we get this
functionality back again?

> -- 
> 2.11.0

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2019-05-11 12:05 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-13  6:32 bug#35254: 27.0.50; cc-mode/electric-pair-mode/electric-layout-mode: bad trailing whitespace behavior in cc-mode Dima Kogan
2019-05-11  3:12 ` Noam Postavsky
2019-05-11 12:05   ` Alan Mackenzie [this message]
     [not found]   ` <20190511120524.GA15991@ACM>
2019-05-11 14:06     ` Noam Postavsky
2019-05-11 16:19       ` Alan Mackenzie
2019-05-11 19:34         ` Basil L. Contovounesios
2019-05-12 16:14           ` Alan Mackenzie
2019-05-12 21:45             ` Basil L. Contovounesios
2019-05-13 10:14               ` Alan Mackenzie
     [not found]               ` <20190513101448.GA5525@ACM>
2019-05-13 12:49                 ` Basil L. Contovounesios
2019-05-12 15:12         ` Alan Mackenzie
2019-05-12 18:42           ` Noam Postavsky
2019-05-13 19:53   ` Alan Mackenzie
     [not found]   ` <20190513195323.GB5525@ACM>
2019-05-13 22:39     ` João Távora
2019-05-13 23:38       ` Noam Postavsky
2019-05-14  1:20         ` João Távora
2019-05-14  1:28         ` Stefan Monnier
2019-05-14  1:56       ` Noam Postavsky
2019-05-14  8:38       ` Alan Mackenzie
2019-05-13 23:32     ` Stefan Monnier
     [not found]     ` <jwvimue9bzj.fsf-monnier+emacs@gnu.org>
2019-05-13 23:45       ` Noam Postavsky
2019-05-14  1:26         ` Stefan Monnier
2019-05-14  9:27       ` Alan Mackenzie
2019-05-14  9:34       ` Alan Mackenzie
     [not found]       ` <20190514092735.GB4231@ACM>
2019-05-14 10:34         ` João Távora
2019-05-15 10:03           ` Alan Mackenzie
2019-05-15 11:27             ` João Távora
2019-05-15 13:19               ` Stefan Monnier
2019-05-15 13:55                 ` João Távora
2019-05-15 14:03                   ` João Távora
2019-07-01 12:24                   ` João Távora
2019-07-01 13:34                     ` Alan Mackenzie
     [not found]                     ` <20190701133427.GA23312@ACM>
2019-07-06 16:24                       ` Noam Postavsky
2019-07-06 22:24                         ` João Távora
2019-07-06 22:50                           ` Noam Postavsky
2019-07-06 22:33                       ` João Távora
     [not found]       ` <20190514093415.GC4231@ACM>
2019-05-14 15:38         ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='20190511120524.GA15991__9936.80583066947$1557576394$gmane$org@ACM' \
    --to=acm@muc.de \
    --cc=35254@debbugs.gnu.org \
    --cc=dima@secretsauce.net \
    --cc=joaotavora@gmail.com \
    --cc=npostavs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).