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: Sat, 11 May 2019 10:06:42 -0400 Message-ID: <87sgtlhyq5.fsf@gmail.com> References: <87ftqms9db.fsf@secretsauce.net> <871s15k7ll.fsf@gmail.com> <20190511120524.GA15991@ACM> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="41290"; 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 Sat May 11 16:26:11 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 1hPSwy-000AaV-KR for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 May 2019 16:26:08 +0200 Original-Received: from localhost ([127.0.0.1]:59688 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPSwx-0002zU-MH for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 May 2019 10:26:07 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36392) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPSqW-0004Pt-86 for bug-gnu-emacs@gnu.org; Sat, 11 May 2019 10:19:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPSeU-0004cq-U9 for bug-gnu-emacs@gnu.org; Sat, 11 May 2019 10:07:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55431) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hPSeU-0004cg-QK; Sat, 11 May 2019 10:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hPSeU-0007sM-H2; Sat, 11 May 2019 10:07: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: Sat, 11 May 2019 14:07: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.155758361230258 (code B ref 35254); Sat, 11 May 2019 14:07:02 +0000 Original-Received: (at 35254) by debbugs.gnu.org; 11 May 2019 14:06:52 +0000 Original-Received: from localhost ([127.0.0.1]:40742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPSeJ-0007ry-Rj for submit@debbugs.gnu.org; Sat, 11 May 2019 10:06:52 -0400 Original-Received: from mail-io1-f43.google.com ([209.85.166.43]:42836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPSeH-0007rk-SX for 35254@debbugs.gnu.org; Sat, 11 May 2019 10:06:50 -0400 Original-Received: by mail-io1-f43.google.com with SMTP id g16so6711975iom.9 for <35254@debbugs.gnu.org>; Sat, 11 May 2019 07:06:49 -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=78nAC5t6YU8RIWfyja3684dyg6R8l4Q19TpdCSH1EYs=; b=pUF8pAZ/vTXDDGbpl+aDY3F+64L3alc6MlX7+BjfbtmY2nGIofnq3zrl+XEJYpM/VX ahOE5cL4Ei57eCFQvfZ8VOVY8hFIqy24IWaqEbnoCciqJw+wmltQ6TUctiG0kko6V9CU PSiRdyKcqrd4QV2RbeNqGd9nW5NFk4ZfofZfuDlCZA6PkOM43x1wEbEbOAsFq6vlEX+u /Piu8wOKXxtailr6U/TMPrItJIWe2NVsQgT1BTPtbo3wVmow2Ee5H2k42ZhCDgbvjZ1D q73yqMPELKgRSr/IoPiPZD//EjiA1etwcjRqYW0RhH7LlHRqOQE/MP9cNWD3Jh1BJ0BZ /nOw== 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=78nAC5t6YU8RIWfyja3684dyg6R8l4Q19TpdCSH1EYs=; b=M4W5xyHQ/Dh/fMMjPC5yydy6CM0hx1ToYjxSMdsBwKxpHOeygvCH66h87eDaYoTePf ohmuIvzuPXzN00x0j9vV8NCKZ/eMSdEk70aifYPZJodmp08ZY+IZKjqmyz0zE+3NYdTJ XPBSACbtYo3Xdg8RGSPkAzX7nMAu+tD+ECoDwOM4RfSMqR5YmndvyxbKDQuRHt7b6dGO v/tFpTB/90mN5/POE5a8DvcptGYpZYZdaeaLsP3isEHwjGRaRH10lChTcIxN2kZixpxX ejBUY+1TzOh0/HblwYYf6+4OVWJCwDeSEw5NFXiU+I443nSKYOcCAoOr1yXkbEBQ9hcP WSjw== X-Gm-Message-State: APjAAAUh3zVNuP3qUPBnVQR1cKeqR9Ro8EDabi1vBgV9+S2NitGrP06R H07ytBBIdqRcmwjccnJk0iI= X-Google-Smtp-Source: APXvYqwg113Rwo9WnMk/Juqf/H9YplEJJO56mn3b/SuwNjEO3BXWkT5b9vHmMr9veImW/UEqP8phQw== X-Received: by 2002:a6b:8f51:: with SMTP id r78mr10799815iod.110.1557583604166; Sat, 11 May 2019 07:06:44 -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 129sm3246466iow.32.2019.05.11.07.06.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 11 May 2019 07:06:43 -0700 (PDT) In-Reply-To: <20190511120524.GA15991@ACM> (Alan Mackenzie's message of "Sat, 11 May 2019 12:05:24 +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:159087 Archived-At: 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? >> 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"). >> 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. 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. 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).