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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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'



Reply | Threaded
Open this post in threaded view
|

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

Allen Li
Attached patch.  This seems like a reasonable and trivial change, so I
haven't updated NEWS or :version for defcustom.

0001-Add-leading-space-to-battery-mode-line-format.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Allen Li
> From: Allen Li <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Glenn Morris-3
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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Glenn Morris <[hidden email]>
> Cc: Allen Li <[hidden email]>,  [hidden email]
> 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?



Reply | Threaded
Open this post in threaded view
|

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

Allen Li
On Wed, Jan 10, 2018 at 11:05 AM, Eli Zaretskii <[hidden email]> wrote:

>> From: Glenn Morris <[hidden email]>
>> Cc: Allen Li <[hidden email]>,  [hidden email]
>> 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?



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Allen Li <[hidden email]>
> Date: Wed, 10 Jan 2018 15:26:42 -0800
> Cc: Glenn Morris <[hidden email]>, [hidden email]
>
> >> 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?



Reply | Threaded
Open this post in threaded view
|

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.