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 16:19:03 +0000 [thread overview]
Message-ID: <20190511161903.GB15991@ACM> (raw)
In-Reply-To: <87sgtlhyq5.fsf@gmail.com>
Hello, Noam.
On Sat, May 11, 2019 at 10:06:42 -0400, Noam Postavsky wrote:
> Alan Mackenzie <acm@muc.de> writes:
> [rearranged a bit for better flow]
:-)
> >> 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.
> >> Subject: [PATCH] Inhibit electric indent completely in cc mode buffers
> >> 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).
> > I don't quite agree with this. The problem is confusion between effect
> > 2 [above] 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.
> So we should have an electric-delete-trailing-whitespace-mode?
NO, NO, NO, NO, NO, NO, NO!!!!
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.
> >> 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).
> >> (when (boundp 'electric-indent-inhibit) (setq electric-indent-inhibit t))
> >> + (add-hook 'electric-indent-functions 'c-electric-indent-mode-function nil t)
> >> +(defun c-electric-indent-mode-function (char)
> >> + ;; We never want `electric-indent-mode' to do anything.
> >> + 'no-indent)
> > 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.
> Hmm, from my point of view, the whole point of the patch is to
> *UNcouple* CC mode from electric.el's electric indentation (since CC
> mode has its own electric functionality), something that
> electric-indent-inhibit does only partially (and based on your response
> above I guess the reason for being partial is that there is some
> disagreement over which parts exactly constitute "electric
> indentation").
This further incursion of electric- stuff into CC Mode is an inevitable
consequence of the confusion described above. Again, setting a single
flag saying NO! should be enough, without having to configure the
mechanisms which are supposedly disabled.
> >> 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'.
> > 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?
> Both these commands still exist. As far as I can tell, `newline' never
> removed trailing WS.
I think you're right. It might even have been an annoyance at the time.
Personally I always used `newline-and-indent', bound to C-j.
> It does have some code to delete the "left margin", but that doesn't
> seem to be intended for programming modes where the margin is 0
> (disabled).
> `newline-and-indent' did, and still does, delete trailing whitespace.
> In 24.4, C-j was rebound from `newline-and-indent' to
> `electric-newline-and-maybe-indent' which only calls
> `newline-and-indent' if `electric-indent-mode' is nil.
Yes. The ability simply to switch over the two keys between `newline'
and `newline-and-indent' by an option was confused into
electric-indent-mode, something I protested strongly against at the time.
My objections were not addressed, they were simply evaded and brushed
aside.
> Of course c-mode could rebind it in its mode map (I considered making
> `electric-newline-and-maybe-indent' consult `electric-indent-functions'
> as well but that won't work because that hook is supposed to run after
> the character is inserted).
I think we've got enough foggy complexity in the area as it is. I
suppose CC Mode could bind <CR> to `newline-and-indent', but there's now
no longer a clean function which does what `newline' used to do, to bind
onto C-j.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2019-05-11 16:19 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 [this message]
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=20190511161903.GB15991@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).