unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Phil Sainty <psainty@orcon.net.nz>
To: Alan Mackenzie <acm@muc.de>
Cc: 2034@debbugs.gnu.org,
	bug-gnu-emacs
	<bug-gnu-emacs-bounces+psainty=orcon.net.nz@gnu.org>
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	[thread overview]
Message-ID: <18b94c97-36e1-48f5-5fa3-105c02c9d0ba@orcon.net.nz> (raw)
In-Reply-To: <6151a9339904bddb78507bc20d8484d6@webmail.orcon.net.nz>

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






  reply	other threads:[~2018-07-08  2:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8cbpgkqwkt.fsf@fencepost.gnu.org>
2009-01-25  2:10 ` bug#2034: 23.0.60; c-subword-mode incompatible with xml-mode me
2009-01-25 15:44   ` Stefan Monnier
2009-01-25 18:48     ` Ross Patterson
2010-01-23 22:36   ` bug#2034: marked as done (23.0.60; c-subword-mode incompatible with xml-mode) Emacs bug Tracking System
2018-07-02 12:40   ` bug#2034: [PATCH] 27.0.50; Support mode line constructs for `mode-name' in c-mode Phil Sainty
2018-07-02 15:29     ` Eli Zaretskii
2018-07-02 22:53       ` Phil Sainty
2018-07-03 13:37         ` Phil Sainty
2018-07-04  2:41         ` Eli Zaretskii
     [not found]   ` <mailman.3006.1530625089.1292.bug-gnu-emacs@gnu.org>
2018-07-04 20:11     ` Alan Mackenzie
2018-07-04 21:13       ` Phil Sainty
2018-07-08  2:46         ` Phil Sainty [this message]
2018-07-08 20:08         ` Alan Mackenzie
2018-07-09 14:47           ` Phil Sainty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18b94c97-36e1-48f5-5fa3-105c02c9d0ba@orcon.net.nz \
    --to=psainty@orcon.net.nz \
    --cc=2034@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=bug-gnu-emacs-bounces+psainty=orcon.net.nz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).