From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.bugs Subject: bug#2034: [PATCH] 27.0.50; Support mode line constructs for `mode-name' in c-mode Date: Thu, 05 Jul 2018 09:13:38 +1200 Message-ID: <6151a9339904bddb78507bc20d8484d6@webmail.orcon.net.nz> References: <87skn8xhia.fsf@transitory.lefae.org> <20180704201150.74826.qmail@mail.muc.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1530738729 20642 195.159.176.226 (4 Jul 2018 21:12:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2018 21:12:09 +0000 (UTC) User-Agent: Orcon Webmail Cc: 2034@debbugs.gnu.org, bug-gnu-emacs To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 04 23:12:05 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fap4H-0005FM-7W for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jul 2018 23:12:05 +0200 Original-Received: from localhost ([::1]:49267 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fap6M-0005C2-Kf for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jul 2018 17:14:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fap6F-0005BJ-92 for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2018 17:14:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fap6A-0008Gt-90 for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2018 17:14:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39138) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fap6A-0008Gd-4a for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2018 17:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fap69-0001rW-Ur for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2018 17:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Jul 2018 21:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 2034 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug wontfix Original-Received: via spool by 2034-submit@debbugs.gnu.org id=B2034.15307388247123 (code B ref 2034); Wed, 04 Jul 2018 21:14:01 +0000 Original-Received: (at 2034) by debbugs.gnu.org; 4 Jul 2018 21:13:44 +0000 Original-Received: from localhost ([127.0.0.1]:47035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fap5s-0001qm-3t for submit@debbugs.gnu.org; Wed, 04 Jul 2018 17:13:44 -0400 Original-Received: from smtp-1.orcon.net.nz ([60.234.4.34]:46185) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fap5p-0001qd-Dr for 2034@debbugs.gnu.org; Wed, 04 Jul 2018 17:13:42 -0400 Original-Received: from [10.253.37.70] (port=36746 helo=webmail.orcon.net.nz) by smtp-1.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1fap5m-0003sS-E3; Thu, 05 Jul 2018 09:13:38 +1200 Original-Received: from wlgwil-nat-office.catalyst.net.nz ([202.78.240.7]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Thu, 05 Jul 2018 09:13:38 +1200 In-Reply-To: <20180704201150.74826.qmail@mail.muc.de> X-Sender: psainty@orcon.net.nz X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- 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: 208.118.235.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:148206 Archived-At: Hi Alan, On 2018-07-05 08:11, Alan Mackenzie wrote: > But I must confess, I'm not filled with enthusiasm by this change. > What > is the problem it is fixing? The original problem (use of a CC Mode > command by a non CC Mode mode) went away when cc-subword.el became just > subword-mode. I believe the original problem was the same as the problem I'm aiming to fix, which is that `c-update-modeline' imposes a non-standard restriction upon `mode-name' that it be a simple string (as opposed to containing arbitrary mode line constructs, as it should be able to do). It seems that the original symptom of the problem in this bug report went away as a side-effect of the change to subword-mode, but the bug itself remained. `c-update-modeline' even contains a "FIXME" comment about it: ;; FIXME: Derived modes might want to use something else ;; than a string for `mode-name'. > This change introduces complexity, even if, perhaps, not very much. Do > we really need a buffer local variable for the display of these flags? > (That's a real question, not a rhetorical one.) It seems to be > inviting > misuse, given that it prevails for ever, but is really only valid for > the short time between it being calculated and the mode line being > displayed. In the current version of the patch, the buffer-local variable is used every time the mode line is rendered, as the variable *symbol* is incorporated into `mode-name'. However Stefan made the suggestion that the flags themselves could become a list of mode line constructs, which would then mean it could be a global value rather than a buffer-local one, as each buffer would render that single construct into the appropriate flags for its own buffer. > +(defvar-local c-modeline-flags-major-modes-processed nil > + "Major modes for which `c-update-modeline' has processed > `mode-name'. > > .... seems confused. That was a mistake on my part, and I was intending to change it from a list to a single value record of the most recent `major-mode' to be processed. The reason for having a record in the first place is that a major mode which is *derived* from, say, `c-mode' can trigger `c-update-modeline' repeatedly with different values for `major-mode', and if we see a *new* `major-mode' value then `mode-name' will also have been reset (to a string, in the existing cases), and needs to be processed again, as each major mode body resets `mode-name'. i.e. We need to process `mode-name' exactly once for whatever the final major mode is. Something like: (unless (eq major-mode c-modeline-major-mode)...), with buffer-local `c-modeline-major-mode' then set to the value of `major-mode'. > I'm rather sceptical about > > (setq mode-name (list mode-name ..... > > , which is just screaming out for an unbounded appending of other > things, many times over, if anything goes wrong with the enclosing > `unless' form. What happens to it when the major mode is changed? Hopefully you find the aforementioned proposed change less concerning. > Would it not be possible, somehow, either to leave mode-name > unmolested, > or calculate it unrecursively when needed? Not that I can think of. AFAIK using mode line constructs in `mode-name' is exactly how these kinds of things are supposed to be done. > As a final point, how is the backward compatibility of this change? > How > many former Emacsen will it work in? I've not checked. I think these mode line constructs have been stable for a long time? If a new third-party derived mode was written to have a fancy `mode-name' then obviously that would only work with an Emacs version which contained these changes. I'm not sure what you're getting at here, though... Are you saying that people will use newer cc-mode code with older emacsen? I can do some testing if I know what the use-case is. -Phil