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: Sun, 12 May 2019 15:12:37 +0000	[thread overview]
Message-ID: <20190512151237.GB20053@ACM> (raw)
In-Reply-To: <20190511161903.GB15991@ACM>

Hello again, Noam.

On Sat, May 11, 2019 at 16:19:03 +0000, Alan Mackenzie wrote:
> On Sat, May 11, 2019 at 10:06:42 -0400, Noam Postavsky wrote:
> > 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.

> Again, the cause of the current problem is that the deletion of the
> trailing WS has got mixed up with electric stuff.  General confusion.

> Trailing WS deletion has got NOTHING to do with electric indentation.  It
> was part of `newline-and-indent' long before anybody started trying to
> apply CC Mode's electric stuff to other modes.  It should be part of
> `newline' now, not part of electric-indent-post-self-insert-function.

I think I now understand what's going on.  I was wrong in the previous
paragraph.  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.

The chaotic tangling of newline and electric indentation remains.  I
still think the best way to fix this bug (and the only way to fix its
cause) is to separate out the two functionalities.  If they hadn't been
tangled in the first place, the current bug couldn't have happened.

Back in Emacs 24.3 (or whenever it was), newline and newline-and-indent
were perfectly adequate for the job.  They still are, IMAO.

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.

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?

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).





  parent reply	other threads:[~2019-05-12 15:12 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 [this message]
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=20190512151237.GB20053@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).