GNU bug report logs - #2034
23.0.60; c-subword-mode incompatible with xml-mode

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 2034 <at> debbugs.gnu.org
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

Hello, Phil.

In article <mailman.3006.1530625089.1292.bug-gnu-emacs <at> gnu.org> 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).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.