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: Sun, 8 Jul 2018 14:46:49 +1200 Message-ID: <18b94c97-36e1-48f5-5fa3-105c02c9d0ba@orcon.net.nz> 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=utf-8 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1531017907 4403 195.159.176.226 (8 Jul 2018 02:45:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 8 Jul 2018 02:45:07 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 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 Sun Jul 08 04:45:03 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 1fbzh8-000129-Ff for geb-bug-gnu-emacs@m.gmane.org; Sun, 08 Jul 2018 04:45:02 +0200 Original-Received: from localhost ([::1]:35717 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbzjF-00072f-Dh for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Jul 2018 22:47:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbzj6-00072O-A9 for bug-gnu-emacs@gnu.org; Sat, 07 Jul 2018 22:47:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbzj4-0000am-NF for bug-gnu-emacs@gnu.org; Sat, 07 Jul 2018 22:47:04 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42687) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fbzj4-0000aT-Iq for bug-gnu-emacs@gnu.org; Sat, 07 Jul 2018 22:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fbzj4-00060g-9V for bug-gnu-emacs@gnu.org; Sat, 07 Jul 2018 22:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Jul 2018 02:47: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.153101801623090 (code B ref 2034); Sun, 08 Jul 2018 02:47:02 +0000 Original-Received: (at 2034) by debbugs.gnu.org; 8 Jul 2018 02:46:56 +0000 Original-Received: from localhost ([127.0.0.1]:50584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fbzix-00060M-Pg for submit@debbugs.gnu.org; Sat, 07 Jul 2018 22:46:56 -0400 Original-Received: from smtp-3.orcon.net.nz ([60.234.4.44]:51718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fbziv-00060C-Hu for 2034@debbugs.gnu.org; Sat, 07 Jul 2018 22:46:54 -0400 Original-Received: from [150.107.172.117] (port=19533 helo=[192.168.20.103]) by smtp-3.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1fbzis-0004bW-3M; Sun, 08 Jul 2018 14:46:50 +1200 In-Reply-To: <6151a9339904bddb78507bc20d8484d6@webmail.orcon.net.nz> Content-Language: en-GB X-GeoIP: NZ 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:148324 Archived-At: I've updated branch origin/fix/bug-2034 based on recent discussions. > * lisp/progmodes/cc-vars.el (c-modeline-display-flags): New user > option. > * lisp/progmodes/cc-cmds.el (c-modeline-flags): New variable. > (c--modeline-major-mode): New internal buffer-local variable. > (c-update-modeline): Use mode line constructs, rather than string > concatenation, to optionally include minor mode flags in 'mode-name'. As per Stefan's suggestion, `c-modeline-flags' is now a global variable containing a mode line construct which will render appropriately in any buffer. Its value is: (c-modeline-display-flags ("/" (c-block-comment-flag "*" "/") (c-electric-flag ("l" (c-auto-newline "a"))) (c-hungry-delete-key "h") (c-subword-mode "w"))) As a consequence of the change above, we no longer need to call `c-update-modeline' when toggling the state of one of those minor modes in a buffer, hence: > * lisp/progmodes/cc-cmds.el (c-toggle-auto-newline) > (c-toggle-hungry-state, c-toggle-auto-hungry-state) > (c-toggle-electric-state, c-toggle-comment-style): > * lisp/progmodes/cc-mode.el (c-electric-indent-mode-hook) > (c-electric-indent-local-mode-hook): Remove redundant calls to > 'c-update-modeline'. It is no longer necessary to call this function > every time one of the minor mode states changes. The remaining calls > are in 'c-basic-common-init' (which is called via 'c-common-init' by > all the major modes defined in cc-mode.el), and in the :after-hook of > those modes (which ensures that 'mode-name' is still processed for a > derived mode that doesn't call 'c-common-init' itself). On 05/07/18 08:11, Alan Mackenzie wrote: > 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". All done. Do you still have concerns about these changes, Alan? I've revised some of the code that you were unhappy with, so please have another look at the branch. > As a final point, how is the backward compatibility of this change? > How many former Emacsen will it work in? Let me know if there's anything in particular I should be testing. On 04/07/18 14:41, Eli Zaretskii wrote: > Give each of the substrings you concatenate a different face, and > see what happens after concatenation when the result is shown on the > mode line. This works; although, as per the `mode-line-format' documentation, if a variable is used to store the construct then that variable needs to have a non-nil `risky-local-variable' property, otherwise the text properties are ignored. So both of the following work, provided we have: (put 'c-modeline-flags 'risky-local-variable t) (defvar c-modeline-flags `(c-modeline-display-flags (,(propertize "/") (c-block-comment-flag ,(propertize "*" 'help-echo "Comment style" 'face 'warning) ,(propertize "/" 'help-echo "Comment style" 'face 'hi-yellow)) (c-electric-flag (,(propertize "l" 'help-echo "Electric mode" 'face 'hi-green) (c-auto-newline ,(propertize "a" 'help-echo "Auto-newline mode" 'face 'hi-pink)))) (c-hungry-delete-key ,(propertize "h" 'help-echo "Hungry-delete mode" 'face 'hi-red-b)) (c-subword-mode ,(propertize "w" 'help-echo "Subword mode" 'face 'error))))) (defvar c-modeline-flags '(c-modeline-display-flags ((:propertize "/") (c-block-comment-flag (:propertize "*" help-echo "Comment style" face warning) (:propertize "/" help-echo "Comment style" face hi-yellow)) (c-electric-flag ((:propertize "l" help-echo "Electric mode" face hi-green) (c-auto-newline (:propertize "a" help-echo "Auto-newline mode" face hi-pink)))) (c-hungry-delete-key (:propertize "h" help-echo "Hungry-delete mode" face hi-red-b)) (c-subword-mode (:propertize "w" help-echo "Subword mode" face error))))) As there's nothing dynamic going on in these particular text properties, I'd be inclined to use the former approach over the latter, if properties were to be added. Obviously the faces used are only for testing. I'm not sure that these actually need a face, but the `help-echo' text could be pretty handy for clarifying what these potentially-mysterious characters in the mode line actually mean, for users who don't know. I was also pondering making a mouse click visit "(ccmode) Minor Modes", as that provides the clearest documentation. I've referenced this node a couple of docstrings, but having direct access to it from the flags in question in the mode line could be even more helpful. On 04/07/18 11:57, Phil Sainty wrote: > Grepping for uses of c-update-modeline I found this related comment in > lisp/progmodes/antlr-mode.el: > > (define-derived-mode antlr-mode prog-mode > ;; FIXME: Since it uses cc-mode, it bumps into c-update-modeline's > ;; limitation to mode-name being a string. > ;; '("Antlr." (:eval (cadr (assq antlr-language antlr-language-alist)))) > "Antlr" I've added a second commit to the branch which restores this intended construct for `antlr-mode', which makes that more dynamic than the `mode-name' that it was using. -Phil