bug#2034: [PATCH] 27.0.50; Support mode line constructs for `mode-name' in c-mode

[Alan Mackenzie <acm@muc.de>]

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).