From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Noam Postavsky 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: Sun, 12 May 2019 14:42:30 -0400 Message-ID: <87sgtjh5ux.fsf@gmail.com> References: <87ftqms9db.fsf@secretsauce.net> <871s15k7ll.fsf@gmail.com> <20190511120524.GA15991@ACM> <87sgtlhyq5.fsf@gmail.com> <20190511161903.GB15991@ACM> <20190512151237.GB20053@ACM> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="24208"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: Dima Kogan , 35254@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 12 20:43:15 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 1hPtRK-0006Bm-Dn for geb-bug-gnu-emacs@m.gmane.org; Sun, 12 May 2019 20:43:14 +0200 Original-Received: from localhost ([127.0.0.1]:46166 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPtRJ-0002nK-7G for geb-bug-gnu-emacs@m.gmane.org; Sun, 12 May 2019 14:43:13 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPtRB-0002nE-C1 for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 14:43:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPtRA-0005vb-3u for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 14:43:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57991) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hPtR8-0005pE-7M; Sun, 12 May 2019 14:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hPtR8-0000c9-3Z; Sun, 12 May 2019 14:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sun, 12 May 2019 18:43: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.15576865612327 (code B ref 35254); Sun, 12 May 2019 18:43:02 +0000 Original-Received: (at 35254) by debbugs.gnu.org; 12 May 2019 18:42:41 +0000 Original-Received: from localhost ([127.0.0.1]:43302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPtQm-0000bT-Rx for submit@debbugs.gnu.org; Sun, 12 May 2019 14:42:41 -0400 Original-Received: from mail-it1-f169.google.com ([209.85.166.169]:53203) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPtQk-0000bE-F3 for 35254@debbugs.gnu.org; Sun, 12 May 2019 14:42:39 -0400 Original-Received: by mail-it1-f169.google.com with SMTP id q65so16989391itg.2 for <35254@debbugs.gnu.org>; Sun, 12 May 2019 11:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=YhxDP2AaTYmEBaVHOzRjW9MMm1q9rCevQkQQz4qXDPk=; b=Gb8RFwcv9r44qTUCkT83B7aHFjH1zaPT0FDt3ONCpN05ER7bMfoP5atVhW2VjmIHk1 UMk0+JfTRAjLySipdbvhjW1demeX2byquD9HvO5HigdtR2/HZ67rtj+b+zUrFaUK4Srw kN673kMBjPZDzeivFnDo7q32pOO0JUWCpz/mKa+VJ/7zIwy8O3xBMsEg3kYF3pZb0K/i k0TM5bgn90zF0LlJ0JJW55AYmwHCgJey1U5OiW1CjBhegc+d8LHAAmOQeobtQM/pykWb ru1tqhffC3UfvbYKd7yPqmqZ4+CDMlfwGAW0r6fn39nUhaH4ANTjaHmOpuW/oa0Y01s/ D01g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=YhxDP2AaTYmEBaVHOzRjW9MMm1q9rCevQkQQz4qXDPk=; b=TLMDL0+0pxc06/tf14Hm86dnc0LPHrvo+NlFJc14jb7PGJgHfIWb3HZ88MKYGoPGLO lG7HG1SxCV0OGo2xz7v2GJiw5CaysO2ZhockTjKOLGT7WfdYtea5e6+1n+9+JGrxaK3p FprfAU6+0JcgrJ1c5IYh+IP5Xzwy6+w04oMWgsRH9ZjDhSAA35oYd7Gv3TTwdYD5jfI4 yBlbf+oG19I5f+w8wKMnoA0Jn8pMz9Asw2pdNqZO0f1mj3XuCAyVa1JKQvFegxGQJrh8 6ss11OzBsRB1tYtc7snjo/q8T3YKnsqDnTgoYfr6rM08jMaowZcFX01PkIbxviJwjDiZ DgFQ== X-Gm-Message-State: APjAAAU46imzz/R0Wqb987ZY3y0EvxwCuGE/n/tjX8Fz8PxmzZlCQg5n VYX5J0IGumFsy+yfzdkSp3o= X-Google-Smtp-Source: APXvYqynJrWr4Vl252rm9BY1fkLWuILqFXbIQXctlBrXISXQtqHjiCsUE9ZiB5E+keWFde/Rx3xMSQ== X-Received: by 2002:a24:5255:: with SMTP id d82mr8177803itb.104.1557686552669; Sun, 12 May 2019 11:42:32 -0700 (PDT) Original-Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id w194sm3561719itb.33.2019.05.12.11.42.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 12 May 2019 11:42:31 -0700 (PDT) In-Reply-To: <20190512151237.GB20053@ACM> (Alan Mackenzie's message of "Sun, 12 May 2019 15:12:37 +0000") 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:159146 Archived-At: --=-=-= Content-Type: text/plain Alan Mackenzie 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 ; 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) --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Bind-RET-to-newline-and-indent-Bug-35254.patch Content-Description: patch >From cbaf6ee73f9129fdb8f1e45ba680ca029981d290 Mon Sep 17 00:00:00 2001 From: Noam Postavsky 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 --=-=-= Content-Type: text/plain > 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? --=-=-=--