[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#2034: [PATCH] 27.0.50; Support mode line constructs for `mode-name'
From: |
Phil Sainty |
Subject: |
bug#2034: [PATCH] 27.0.50; Support mode line constructs for `mode-name' in c-mode |
Date: |
Tue, 3 Jul 2018 00:40:49 +1200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
`c-update-modeline' in cc-cmds.el has a long-standing bug (and FIXME
comment) whereby a `mode-name' which is not a string will trigger
errors, on account of the function using string manipulations to add
the minor mode flags to the original `mode-name'.
This is what bug #2034 was originally about. i.e.:
> c-update-modeline: Wrong type argument: stringp,
> (sgml-xml-mode "XML" "SGML")
This new patch instead uses mode-line constructs to concatenate the
flags, thus eliminating the string manipulation code and this bug.
In the process I've added a user option to allow the user to choose
whether or not these flags should be displayed at all, as this was not
previously configurable.
e.g.: `c-update-modeline' will now convert the mode-name "C++" into
'("C++" (c-modeline-display-flags c-modeline-flags)); and it only
updates the buffer-local value of `c-modeline-flags' which is then
conditionally displayed based on option `c-modeline-display-flags'.
This bug fix also resolves an incompatibility with the `delight'
package in GNU ELPA, which wraps any targeted `mode-name' values
in additional mode line constructs, and consequently triggered the
`c-update-modeline' bug with its assumption of a string, when used
with any of the major modes in question.
In my testing thus far this new approach seems to work nicely.
-Phil
0001-Support-mode-line-constructs-for-mode-name-in-c-mode.patch
Description: Text Data
- bug#2034: [PATCH] 27.0.50; Support mode line constructs for `mode-name' in c-mode,
Phil Sainty <=