From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie 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: Sat, 11 May 2019 16:19:03 +0000 Message-ID: <20190511161903.GB15991@ACM> References: <87ftqms9db.fsf@secretsauce.net> <871s15k7ll.fsf@gmail.com> <20190511120524.GA15991@ACM> <87sgtlhyq5.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="997"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Dima Kogan , 35254@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 11 18:20:16 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 1hPUjP-000065-Uz for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 May 2019 18:20:16 +0200 Original-Received: from localhost ([127.0.0.1]:32986 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPUjP-0008AR-0Y for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 May 2019 12:20:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPUjG-00089i-AD for bug-gnu-emacs@gnu.org; Sat, 11 May 2019 12:20:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPUjE-00015y-Ue for bug-gnu-emacs@gnu.org; Sat, 11 May 2019 12:20:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55566) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hPUjC-00014e-30; Sat, 11 May 2019 12:20:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hPUjB-0006rD-TI; Sat, 11 May 2019 12:20:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sat, 11 May 2019 16:20:01 +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.155759155026299 (code B ref 35254); Sat, 11 May 2019 16:20:01 +0000 Original-Received: (at 35254) by debbugs.gnu.org; 11 May 2019 16:19:10 +0000 Original-Received: from localhost ([127.0.0.1]:40877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPUiM-0006q7-BI for submit@debbugs.gnu.org; Sat, 11 May 2019 12:19:10 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:31603 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hPUiJ-0006px-F8 for 35254@debbugs.gnu.org; Sat, 11 May 2019 12:19:08 -0400 Original-Received: (qmail 23104 invoked by uid 3782); 11 May 2019 16:19:04 -0000 Original-Received: from acm.muc.de (p2E5D55A8.dip0.t-ipconnect.de [46.93.85.168]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 11 May 2019 18:19:03 +0200 Original-Received: (qmail 13129 invoked by uid 1000); 11 May 2019 16:19:03 -0000 Content-Disposition: inline In-Reply-To: <87sgtlhyq5.fsf@gmail.com> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de 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:159092 Archived-At: Hello, Noam. On Sat, May 11, 2019 at 10:06:42 -0400, Noam Postavsky wrote: > Alan Mackenzie 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 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).