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: 4 Jul 2018 20:11:50 -0000 Organization: muc.de e.V. Message-ID: <20180704201150.74826.qmail@mail.muc.de> References: <87skn8xhia.fsf@transitory.lefae.org> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1530735040 30027 195.159.176.226 (4 Jul 2018 20:10:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2018 20:10:40 +0000 (UTC) User-Agent: tin/2.4.2-20171224 ("Lochhead") (UNIX) (FreeBSD/11.1-RELEASE-p10 (amd64)) Cc: 2034@debbugs.gnu.org To: Phil Sainty Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 04 22:10:35 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 1fao6h-0007bI-U2 for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jul 2018 22:10:32 +0200 Original-Received: from localhost ([::1]:49106 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fao8p-0001En-7C for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jul 2018 16:12:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fao8F-0000uO-CK for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2018 16:12:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fao8A-0006Ue-Cm for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2018 16:12:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39125) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fao8A-0006UY-9j for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2018 16:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fao8A-0000QP-4u for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2018 16:12: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: Wed, 04 Jul 2018 20:12: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.15307351141619 (code B ref 2034); Wed, 04 Jul 2018 20:12:02 +0000 Original-Received: (at 2034) by debbugs.gnu.org; 4 Jul 2018 20:11:54 +0000 Original-Received: from localhost ([127.0.0.1]:47022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fao82-0000Q2-3N for submit@debbugs.gnu.org; Wed, 04 Jul 2018 16:11:54 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:23203 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1fao80-0000Pu-4A for 2034@debbugs.gnu.org; Wed, 04 Jul 2018 16:11:52 -0400 Original-Received: (qmail 74827 invoked by uid 3782); 4 Jul 2018 20:11:50 -0000 In-Reply-To: X-Newsgroups: gnu.emacs.bug 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:148205 Archived-At: Hello, Phil. In article you wrote: > On 03/07/18 10:53, Phil Sainty wrote: >> I'll write a revised patch to address these points. > An updated version is on branch origin/fix/bug-2034 with the > following change log. > Support mode line constructs for 'mode-name' in c-mode (bug#2034) > Also make the inclusion of minor mode flags in 'mode-name' optional. > * lisp/progmodes/cc-cmds.el (c-modeline-flags): New variable. > (c-modeline-flags-major-modes-processed): New variable. > (c-modeline-display-flags): New user option. > (c-update-modeline): Use them. Use mode line constructs, rather than > string concatenation, to optionally include minor mode flags in > 'mode-name'. > * lisp/progmodes/cc-mode.el (c-submit-bug-report): Format 'mode-name'. > * lisp/progmodes/cc-styles.el (c-set-style): Format 'mode-name'. > * etc/NEWS: Mention new user option and behaviors. > * doc/misc/cc-mode.texi: Document 'c-modeline-display-flags'. For fitting in better with CC Mode, please: (i) Put c-modeline-display-flags (and any other configuration variables) in cc-vars.el rather than cc-cmds.el. (ii) In cc-mode.info, make a second @vindex entry for your new variable, like all the other variables have two @vindexes. Also, in chapter "Minor Modes", I'd be happier if the paragraph beginning "@ccmode{} displays the current state" was amended to something like "@ccmode{}, by default, displays the current state". 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. 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. +(defvar-local c-modeline-flags-major-modes-processed nil + "Major modes for which `c-update-modeline' has processed `mode-name'. .... seems confused. It's a poor quality doc string, since it doesn't say what the format is: is it a list of major modes, or a list of major mode names, or what? Why is this collection of major modes relevant to a single buffer? What's the purpose of the variable? 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? Would it not be possible, somehow, either to leave mode-name unmolested, or calculate it unrecursively when needed? As a final point, how is the backward compatibility of this change? How many former Emacsen will it work in? -- Alan Mackenzie (Nuremberg, Germany).