all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Noam Postavsky <npostavs@gmail.com>
To: Alan Mackenzie <acm@muc.de>
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: Sun, 12 May 2019 14:42:30 -0400	[thread overview]
Message-ID: <87sgtjh5ux.fsf@gmail.com> (raw)
In-Reply-To: <20190512151237.GB20053@ACM> (Alan Mackenzie's message of "Sun, 12 May 2019 15:12:37 +0000")

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

Alan Mackenzie <acm@muc.de> writes:

>> > So we should have an electric-delete-trailing-whitespace-mode?
>
>> NO, NO, NO, NO, NO, NO, NO!!!!
>
> First of all, apologies for being so unecessarily emphatic, yesterday.

To be honest, I've gotten used to you being very emphatic in most of
your posts, so it didn't really phase me.

> The connection between WS deletion and newline-and-indent/electric
> indentation is that when n-a-i/e-i is in play, Emacs assumes that the
> trailing WS on a line was put there by a previous use of n-a-i/e-i,
> therefore it's the Right Thing to remove it.  Otherwise (newline, no
> electric indentation) the trailing WS stays.

Yes, this sounds right to me.

> I propose that newline be restored to its former functionality (i.e.
> with no indentation of the new line) and be bound to C-j; that
> newline-and-indent become the standard binding for <CR>; that
> indentation of a new line no longer be done by electric indentation,
> since this is not needed; that the grossly misnamed, and now redundant
> electric-indent-just-newline and the command of dubious utility
> electric-newline-and-maybe-indent both be made obsolete.

So like this: (I didn't do any obsoletion, since it doesn't affect
testing)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1958 bytes --]

From cbaf6ee73f9129fdb8f1e45ba680ca029981d290 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Sun, 12 May 2019 13:53:31 -0400
Subject: [PATCH] Bind RET to newline-and-indent (Bug#35254)

* lisp/bindings.el: Bind RET to newline-and-indent, C-j to newline.
* lisp/electric.el: Don't bind electric-newline-and-maybe-indent to
C-j.
(electric-indent-chars): Remove newline from default value.
---
 lisp/bindings.el | 3 ++-
 lisp/electric.el | 4 +---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/lisp/bindings.el b/lisp/bindings.el
index 744bcc36a8..43b4f8b8cf 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -892,7 +892,8 @@ (define-key global-map "\C-g" 'keyboard-quit)
 ;; suspend only the relevant terminal.
 (substitute-key-definition 'suspend-emacs 'suspend-frame global-map)
 
-(define-key global-map "\C-m" 'newline)
+(define-key global-map "\C-m" 'newline-and-indent)
+(define-key global-map "\C-j" 'newline)
 (define-key global-map "\C-o" 'open-line)
 (define-key esc-map "\C-o" 'split-line)
 (define-key global-map "\C-q" 'quoted-insert)
diff --git a/lisp/electric.el b/lisp/electric.el
index 07da2f1d9e..e5c318e34f 100644
--- a/lisp/electric.el
+++ b/lisp/electric.el
@@ -207,7 +207,7 @@ (defun electric--sort-post-self-insertion-hook ()
 ;; should usually set this variable by adding elements to the default
 ;; value, which only works well if the variable is preloaded.
 ;;;###autoload
-(defvar electric-indent-chars '(?\n)
+(defvar electric-indent-chars '()
   "Characters that should cause automatic reindentation.")
 
 (defvar electric-indent-functions nil
@@ -306,8 +306,6 @@ (defun electric-indent-just-newline (arg)
     (newline arg 'interactive)))
 
 ;;;###autoload
-(define-key global-map "\C-j" 'electric-newline-and-maybe-indent)
-;;;###autoload
 (defun electric-newline-and-maybe-indent ()
   "Insert a newline.
 If `electric-indent-mode' is enabled, that's that, but if it
-- 
2.11.0


[-- Attachment #3: Type: text/plain, Size: 1258 bytes --]


> The above amendments will leave the behaviour of Emacs unchanged for the
> normal user.  They will cause mild incompatibilities, the inverse of
> those which were caused in 24.4 (or whenever), when the current setup
> was set up.
>
> Then bugs like the current one will no longer happen in the future.
>
> Clearly this would need to be discussed and settled in emacs-devel,
> first.
>
> What do you say?

I'm one of the "normal" users who wouldn't be affected, so it's fine for
me.  And I kind of think binding C-j to newline makes more sense anyway
(?\C-j is literally the newline character, after all).  Pushing through
changes to default keybindings is always a tricky proposition though.  I
have the impression that part of the reason for implementing the newline
indentation via electric mode was because of this (i.e., add auto
indentation to RET, without changing its binding).

On the other hand, I don't think the idea of letting electric mode
handle the indent on newline is quite so illogical as you say.  The idea
of electric indent, as I understand it, is that when you insert some
character, Emacs will automatically perform indentation for you.
Newline is a character, so why not let electric indent perform
indentation after inserting it?

  reply	other threads:[~2019-05-12 18:42 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
     [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 [this message]
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

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

  git send-email \
    --in-reply-to=87sgtjh5ux.fsf@gmail.com \
    --to=npostavs@gmail.com \
    --cc=35254@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=dima@secretsauce.net \
    --cc=joaotavora@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.