From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#2034: [PATCH] 27.0.50; Support mode line constructs for `mode-name' in c-mode Date: Sun, 8 Jul 2018 20:08:54 +0000 Message-ID: <20180708200854.GA6311@ACM> References: <87skn8xhia.fsf@transitory.lefae.org> <20180704201150.74826.qmail@mail.muc.de> <6151a9339904bddb78507bc20d8484d6@webmail.orcon.net.nz> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1531081089 23444 195.159.176.226 (8 Jul 2018 20:18:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 8 Jul 2018 20:18:09 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: 2034@debbugs.gnu.org, bug-gnu-emacs To: Phil Sainty Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 08 22:18:04 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 1fcG8B-0005yZ-V0 for geb-bug-gnu-emacs@m.gmane.org; Sun, 08 Jul 2018 22:18:04 +0200 Original-Received: from localhost ([::1]:38115 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fcGAJ-0003No-47 for geb-bug-gnu-emacs@m.gmane.org; Sun, 08 Jul 2018 16:20:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fcGA9-0003NY-T3 for bug-gnu-emacs@gnu.org; Sun, 08 Jul 2018 16:20:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fcGA6-0001lD-Me for bug-gnu-emacs@gnu.org; Sun, 08 Jul 2018 16:20:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43573) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fcGA6-0001l6-HB for bug-gnu-emacs@gnu.org; Sun, 08 Jul 2018 16:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fcGA6-0007qZ-5L for bug-gnu-emacs@gnu.org; Sun, 08 Jul 2018 16:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Jul 2018 20:20:02 +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.153108118630137 (code B ref 2034); Sun, 08 Jul 2018 20:20:02 +0000 Original-Received: (at 2034) by debbugs.gnu.org; 8 Jul 2018 20:19:46 +0000 Original-Received: from localhost ([127.0.0.1]:51470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fcG9p-0007q1-Ip for submit@debbugs.gnu.org; Sun, 08 Jul 2018 16:19:45 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:63489 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1fcG9n-0007pr-Rp for 2034@debbugs.gnu.org; Sun, 08 Jul 2018 16:19:44 -0400 Original-Received: (qmail 71228 invoked by uid 3782); 8 Jul 2018 20:19:42 -0000 Original-Received: from acm.muc.de (p5B14603D.dip0.t-ipconnect.de [91.20.96.61]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 08 Jul 2018 22:19:40 +0200 Original-Received: (qmail 6469 invoked by uid 1000); 8 Jul 2018 20:08:54 -0000 Content-Disposition: inline In-Reply-To: <6151a9339904bddb78507bc20d8484d6@webmail.orcon.net.nz> 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: 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:148365 Archived-At: Hello, Phil. Just as an aside, something in the email chain between you and me has irritatingly formatted your (and my) text like this: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXX , with every second line containing just one (or two) words. Would you please consider investigating this a little. On Thu, Jul 05, 2018 at 09:13:38 +1200, Phil Sainty wrote: > 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). That's unnecessarily harsh. The problem is that the definition of mode-name was changed incompatibly some while back. This seems a foolish change - the name of a mode is essentially a string, and changing this has led to problems. The current code in CC Mode conforms to the original definition of mode-name. > 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'. Why should anybody want to do that? (Not a rhetorical question). > > 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'. This emphasises my earlier comment about the foolishness of the change to the definition of mode-name. > i.e. We need to process `mode-name' exactly once for whatever the final > major mode is. mode-name belongs to the major mode, and shouldn't be tampered with by other SW. It is part of the mode, as defined on Elisp page "Major Mode Conventions", which states that the major mode set this variable to THE pretty name of the mode. It doesn't state that mode-name is merely a template for manipulation by random code. This, I believe, is the root cause of the bug you are wanting to fix. [ .... ] > > 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. Changes like this made in Emacs without backward compatibility code exacerbate the growing difference between the Emacs version and the upstream version. The incompatible change in mode-name happened in Emacs 23.1. Upstream CC Mode is still compatible with XEmacs, and (probably) with Emacs 22, and it is one of the project's aims to preserve this compatibility as much as possible. Your proposed change destroys it. That means either (i) Half of us have to write compatibility code for both the Emacs version of and upstream CC Mode; or (ii) The compatibility code is confined to upstream CC Mode (which is a royal pain when merging upstream changes into Emacs); or (iii) the new code doesn't get merged into the upstream (likewise a pain). > -Phil -- Alan Mackenzie (Nuremberg, Germany).