The battery-mode-line-string set by battery-update is missing a leading space, causing it to get combined with whatever is before it in the mode line. In GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26) of 2017-12-04 built on arojas Windowing system distributor 'The X.Org Foundation', version 11.0.11906000 Configured using: 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
[-- Attachment #1: Type: text/plain, Size: 119 bytes --] Attached patch. This seems like a reasonable and trivial change, so I haven't updated NEWS or :version for defcustom. [-- Attachment #2: 0001-Add-leading-space-to-battery-mode-line-format.patch --] [-- Type: text/x-patch, Size: 959 bytes --] From e6c0eeaf0f753c6e49013207730642031af181bb Mon Sep 17 00:00:00 2001 From: Allen Li <darkfeline@felesatra.moe> Date: Wed, 10 Jan 2018 00:43:03 -0800 Subject: [PATCH] Add leading space to battery-mode-line-format * lisp/battery.el (battery-mode-line-format): Add leading space. --- lisp/battery.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/battery.el b/lisp/battery.el index ca17ae8fc3..880b3536fb 100644 --- a/lisp/battery.el +++ b/lisp/battery.el @@ -119,9 +119,9 @@ battery-mode-line-limit (defcustom battery-mode-line-format (cond ((eq battery-status-function 'battery-linux-proc-acpi) - "[%b%p%%,%d°C]") + " [%b%p%%,%d°C]") (battery-status-function - "[%b%p%%]")) + " [%b%p%%]")) "Control string formatting the string to display in the mode line. Ordinary characters in the control string are printed as-is, while conversion specifications introduced by a `%' character in the control -- 2.15.1
> From: Allen Li <vianchielfaura@gmail.com>
> Date: Tue, 9 Jan 2018 19:26:46 -0800
>
> The battery-mode-line-string set by battery-update is missing a
> leading space, causing it to get combined with whatever is before it
> in the mode line.
It doesn't get combined here, so please show an example of what you
observe on your system.
Eli Zaretskii wrote: >> The battery-mode-line-string set by battery-update is missing a >> leading space, causing it to get combined with whatever is before it >> in the mode line. > > It doesn't get combined here, so please show an example of what you > observe on your system. M-x display-time-mode M-x display-battery-mode -> 9.05AM 0.45 Mail[100.0%] See also https://debbugs.gnu.org/18164
> From: Glenn Morris <rgm@gnu.org>
> Cc: Allen Li <vianchielfaura@gmail.com>, 30056@debbugs.gnu.org
> Date: Wed, 10 Jan 2018 12:06:47 -0500
>
> M-x display-time-mode
> M-x display-battery-mode
>
> -> 9.05AM 0.45 Mail[100.0%]
>
> See also https://debbugs.gnu.org/18164
We don't do this consistently in the modes which use
global-mode-string: some of them leave a blank at the beginning,
others (the majority, AFACT) don't. There's not much space on the
mode line, so I'm not sure which way is better.
But if we want to have a separation there, would it make sense to do
this in bindings.el, so that global-mode-string is always separated by
a blank from the preceding text, and modes don't have to remember this
gork?
On Wed, Jan 10, 2018 at 11:05 AM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Glenn Morris <rgm@gnu.org> >> Cc: Allen Li <vianchielfaura@gmail.com>, 30056@debbugs.gnu.org >> Date: Wed, 10 Jan 2018 12:06:47 -0500 >> >> M-x display-time-mode >> M-x display-battery-mode >> >> -> 9.05AM 0.45 Mail[100.0%] >> >> See also https://debbugs.gnu.org/18164 > > We don't do this consistently in the modes which use > global-mode-string: some of them leave a blank at the beginning, > others (the majority, AFACT) don't. There's not much space on the > mode line, so I'm not sure which way is better. The standard for minor mode strings is to include a leading space, right? That seems like the right approach for global-mode-strings, which also follows an "append" pattern like minor modes. From what I can grok, the general standard of the mode line is to use spaces at the end for "top level" mode line items (mode-line-modes, mode-line-position) and spaces at the beginning for sub items (minor modes, the parts inside mode-line-position). In any case, Emacs packages should probably be consistent, and currently display-battery-mode and display-time-mode are inconsistent. I don’t know which other modes use global-mode-string; is display-time mode the only outlier? > But if we want to have a separation there, would it make sense to do > this in bindings.el, so that global-mode-string is always separated by > a blank from the preceding text, and modes don't have to remember this > gork?
> From: Allen Li <vianchielfaura@gmail.com> > Date: Wed, 10 Jan 2018 15:26:42 -0800 > Cc: Glenn Morris <rgm@gnu.org>, 30056@debbugs.gnu.org > > >> See also https://debbugs.gnu.org/18164 > > > > We don't do this consistently in the modes which use > > global-mode-string: some of them leave a blank at the beginning, > > others (the majority, AFACT) don't. There's not much space on the > > mode line, so I'm not sure which way is better. > > The standard for minor mode strings is to include a leading space, right? That's just it: I'm not sure. > In any case, Emacs packages should probably be consistent, and > currently display-battery-mode and display-time-mode are inconsistent. > I don’t know which other modes use global-mode-string; is display-time > mode the only outlier? Not at all: grep for that variable in the Emacs source tree, and you will see that most of its users don't start their strings with a blank. Which is why I asked this question: > > But if we want to have a separation there, would it make sense to do > > this in bindings.el, so that global-mode-string is always separated by > > a blank from the preceding text, and modes don't have to remember this > > gork?
Interestingly, when display-battery-mode and display-time-mode are set through my custom file, the battery display comes before the time display. However, toggling either of them interactively will always result in the time display coming before the battery display. The cause of this odd behavior is that display-battery-mode appends and removes its symbol in global-mode-string when it is toggled on or off, while display-time-mode only appends its symbol and does not remove it when it is toggled off. The reason display-battery-mode comes first after Emacs starts is because of how the custom file works; user options are sorted alphabetically and display-battery-mode comes first, so it is appended first. Naturally, this has some implications for whether each display uses leading, trailing, or no space.
Allen Li <vianchielfaura@gmail.com> writes: > The cause of this odd behavior is that display-battery-mode appends > and removes its symbol in global-mode-string when it is toggled on or > off, while display-time-mode only appends its symbol and does not > remove it when it is toggled off. The reason display-battery-mode > comes first after Emacs starts is because of how the custom file > works; user options are sorted alphabetically and display-battery-mode > comes first, so it is appended first. > > Naturally, this has some implications for whether each display uses > leading, trailing, or no space. Indeed. Just a random idea: Would it make sense to add a mode line construct like "%S" to mode-line-format that means "put a space here if there isn't one already"? Then battery could put "%S<current string" into the list? Would that work? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Allen Li <vianchielfaura@gmail.com> writes:
>
>> The cause of this odd behavior is that display-battery-mode appends
>> and removes its symbol in global-mode-string when it is toggled on or
>> off, while display-time-mode only appends its symbol and does not
>> remove it when it is toggled off. The reason display-battery-mode
>> comes first after Emacs starts is because of how the custom file
>> works; user options are sorted alphabetically and display-battery-mode
>> comes first, so it is appended first.
>>
>> Naturally, this has some implications for whether each display uses
>> leading, trailing, or no space.
>
> Indeed. Just a random idea: Would it make sense to add a mode line
> construct like "%S" to mode-line-format that means "put a space here if
> there isn't one already"? Then battery could put "%S<current string"
> into the list?
>
> Would that work?
I find that idea intriguing. It would work, and it's a useful feature
to have as an Emacs Lisp developer, because it provide a robust solution
to the problem of "I want to have a space separation in the mode line,
but I don't know what comes before/after me".
Although personally, I feel a little dirty adding a new %-construct just
for this.
Allen Li <darkfeline@felesatra.moe> writes: > I find that idea intriguing. It would work, and it's a useful feature > to have as an Emacs Lisp developer, because it provide a robust solution > to the problem of "I want to have a space separation in the mode line, > but I don't know what comes before/after me". > > Although personally, I feel a little dirty adding a new %-construct just > for this. I think we either have to do this, or introduce a formal convention for these strings that say either to always add a space to the front or the back of them. I guess we don't really see this much as a problem in practice, because we don't have many of these "non-mode" strings in the mode line. So perhaps settling on a convention and then altering all the instances to follow it would be more efficient -- there's probably just a few dozen of them? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --] On Tue, Aug 11, 2020 at 11:20 AM Lars Ingebrigtsen <larsi@gnus.org> wrote: > Allen Li <darkfeline@felesatra.moe> writes: > > > I find that idea intriguing. It would work, and it's a useful feature > > to have as an Emacs Lisp developer, because it provide a robust solution > > to the problem of "I want to have a space separation in the mode line, > > but I don't know what comes before/after me". > > > > Although personally, I feel a little dirty adding a new %-construct just > > for this. > > I think we either have to do this, or introduce a formal convention for > these strings that say either to always add a space to the front or the > back of them. > > I guess we don't really see this much as a problem in practice, because > we don't have many of these "non-mode" strings in the mode line. > > So perhaps settling on a convention and then altering all the instances > to follow it would be more efficient -- there's probably just a few > dozen of them? > I'm fine with that (I assumed that such a convention already existed previously on this bug's thread). > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no > [-- Attachment #2: Type: text/html, Size: 1837 bytes --]
Lars Ingebrigtsen <larsi@gnus.org> writes: > Indeed. Just a random idea: Would it make sense to add a mode line > construct like "%S" to mode-line-format that means "put a space here if > there isn't one already"? Then battery could put "%S<current string" > into the list? I had a peek at how to implement this, and it's surprisingly hard. The mode line stuff is constructed in three different paths (noprop/string/display), and getting at the "previous character" is different in every case. And I'm not really super enthusiastic about the idea in general, because it means that simple strings (like battery-mode-line-string) will have to be replaced by ("%S" battery-mode-line-string) lists... So perhaps we just have to bite the bullet and introduce a new convention: All `global-mode-string' bits have to start with a space character (and we'll remove the trailing character from `mode-line-modes'). This'll make some of these modes look awkward until they're all fixed. A less breakey change is to institute a different rule: All `global-mode-string' elements have to have a trailing space. That'll be less breakey, but may add spaces before the "----" in terminals. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Lars Ingebrigtsen <larsi@gnus.org> writes: > A less breakey change is to institute a different rule: All > `global-mode-string' elements have to have a trailing space. That'll be > less breakey, but may add spaces before the "----" in terminals. I've now done this, and it doesn't add spaces before the "---" bit. I grepped through the Emacs tree to see whether any other packages have problems in this area, but the ones I skimmed seemed to already adhere to this previous non-convention (i.e., they added a space at the end). But I may have missed some, of course. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
>> A less breakey change is to institute a different rule: All
>> `global-mode-string' elements have to have a trailing space. That'll be
>> less breakey, but may add spaces before the "----" in terminals.
>
> I've now done this, and it doesn't add spaces before the "---" bit.
>
> I grepped through the Emacs tree to see whether any other packages have
> problems in this area, but the ones I skimmed seemed to already adhere
> to this previous non-convention (i.e., they added a space at the end).
> But I may have missed some, of course.
This change broke tab-bar.el that expected that the default value of
mode-line-misc-info contains (global-mode-string ("" global-mode-string " ")).
BTW, 9dfa94aed1 duplicated 3 paragraphs in etc/NEWS.
Juri Linkov <juri@linkov.net> writes: > This change broke tab-bar.el that expected that the default value of > mode-line-misc-info contains (global-mode-string ("" global-mode-string " ")). I've now updated the code in tab-bar.el. But isn't that a brittle way to enable this? The user may have altered the variable value, for instance. > BTW, 9dfa94aed1 duplicated 3 paragraphs in etc/NEWS. Now removed. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
>> This change broke tab-bar.el that expected that the default value of
>> mode-line-misc-info contains (global-mode-string ("" global-mode-string " ")).
>
> I've now updated the code in tab-bar.el. But isn't that a brittle way
> to enable this? The user may have altered the variable value, for instance.
This code is just for convenience to avoid duplication of the global string
on the mode-line and on the tab-bar. When the user alters mode-line-misc-info
manually, then we can assume that the user does this intentionally,
e.g. to force duplication of the global string, etc.
But the default value of mode-line-misc-info doesn't change too often,
so there is no problem.
However, there is another problem: now display-time-string contains
additional trailing space, so when time is displayed on the
right edge on the tab-bar, time string is not aligned nicely anymore.
Now there is the gap between the time string and the right edge of the tab-bar.
How this could be avoided? Maybe tab-bar-format-global now needs
to use 'string-trim' on the result of '(format-mode-line global-mode-string)'?
> However, there is another problem: now display-time-string contains
> additional trailing space, so when time is displayed on the
> right edge on the tab-bar, time string is not aligned nicely anymore.
> Now there is the gap between the time string and the right edge of the tab-bar.
>
> How this could be avoided? Maybe tab-bar-format-global now needs
> to use 'string-trim' on the result of '(format-mode-line global-mode-string)'?
Now added string-trim-right.