bug#30056: 25.3; battery-mode-line-string missing leading space

bug#30056: 25.3; battery-mode-line-string missing leading space

[Allen Li]

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'

bug#30056: [PATCH] Add leading space to battery-mode-line-format

[Allen Li]

[-- 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

bug#30056: 25.3; battery-mode-line-string missing leading space

[Eli Zaretskii]

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

bug#30056: 25.3; battery-mode-line-string missing leading space

[Glenn Morris]

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

bug#30056: 25.3; battery-mode-line-string missing leading space

[Eli Zaretskii]

> 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?

bug#30056: 25.3; battery-mode-line-string missing leading space

[Allen Li]

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?

bug#30056: 25.3; battery-mode-line-string missing leading space

[Eli Zaretskii]

> 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?

bug#30056: 25.3; battery-mode-line-string missing leading space

[Allen Li]

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.

bug#30056: 25.3; battery-mode-line-string missing leading space

[Lars Ingebrigtsen]

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

bug#30056: 25.3; battery-mode-line-string missing leading space

[Allen Li]

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.

bug#30056: 25.3; battery-mode-line-string missing leading space

[Lars Ingebrigtsen]

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

bug#30056: 25.3; battery-mode-line-string missing leading space

[Allen Li]

[-- 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 --]

bug#30056: 25.3; battery-mode-line-string missing leading space

[Lars Ingebrigtsen]

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

bug#30056: 25.3; battery-mode-line-string missing leading space

[Lars Ingebrigtsen]

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

bug#30056: 25.3; battery-mode-line-string missing leading space

[Juri Linkov]

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

bug#30056: 25.3; battery-mode-line-string missing leading space

[Lars Ingebrigtsen]

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

bug#30056: 25.3; battery-mode-line-string missing leading space

[Juri Linkov]

>> 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)'?

bug#30056: 25.3; battery-mode-line-string missing leading space

[Juri Linkov]

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