GNU bug report logs -
#76390
[PATCH] Center lines vertically with line-spacing-vertical-center
Previous Next
To reply to this bug, email your comments to 76390 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76390
; Package
emacs
.
(Tue, 18 Feb 2025 10:43:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Daniel Mendler <mail <at> daniel-mendler.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 18 Feb 2025 10:43:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tags: patch
A few years ago there was a discussion on emacs-devel started by Jesse
Nazario about vertically centering text for line-spacing > 0. A patch
was provided back then by Jesse. I hope to revive the discussion and I
like to provide an updated patch.
Centering text would be particularly useful if the text has a background
color (e.g., hl-line or hi-lock) as demonstrated by the following steps:
1. (setq-local line-spacing 0.5)
2. (hl-line-mode 1)
3. M-x hi-lock-face-symbol-at-point on a symbol at point
The proposal was to add a new variable `line-spacing-vertical-center' to
enable text centering. Maybe it makes sense to use a more general
approach which allows finer control over the alignment, e.g., a variable
`line-spacing-align' which can be set to a floating point number in the
interval [0.0, 1.0]. The value 0.5 means to center the text, 0.0 means
to align the text at the top of the line and 1.0 means to align the text
at the bottom of the line. Fine control over the alignment allows to to
adjust to fine differences of the font and its baseline alignment.
The old discussion can be found at:
https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00660.html
I attached the latest patch from the old discussion to this report.
[centering-text.patch (text/patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76390
; Package
emacs
.
(Tue, 18 Feb 2025 15:15:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76390 <at> debbugs.gnu.org (full text, mbox):
> Cc: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 18 Feb 2025 11:41:26 +0100
> From: Daniel Mendler via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> A few years ago there was a discussion on emacs-devel started by Jesse
> Nazario about vertically centering text for line-spacing > 0. A patch
> was provided back then by Jesse. I hope to revive the discussion and I
> like to provide an updated patch.
>
> Centering text would be particularly useful if the text has a background
> color (e.g., hl-line or hi-lock) as demonstrated by the following steps:
>
> 1. (setq-local line-spacing 0.5)
> 2. (hl-line-mode 1)
> 3. M-x hi-lock-face-symbol-at-point on a symbol at point
>
> The proposal was to add a new variable `line-spacing-vertical-center' to
> enable text centering. Maybe it makes sense to use a more general
> approach which allows finer control over the alignment, e.g., a variable
> `line-spacing-align' which can be set to a floating point number in the
> interval [0.0, 1.0]. The value 0.5 means to center the text, 0.0 means
> to align the text at the top of the line and 1.0 means to align the text
> at the bottom of the line. Fine control over the alignment allows to to
> adjust to fine differences of the font and its baseline alignment.
Rather than introducing yet another buffer-local knob, I think I'd
prefer extending line-spacing to have a cons cell value (with car
applied to ascent and cdr to descent). This will probably need to add
a new field to the iterator struct.
Also, we should support the same extension for the line-spacing
property on the newline ending a line (see the node "Line Height" in
the ELisp manual).
And finally, I have a question: what does this patch do with a line
that mixes different fonts, especially fonts with very different
values of ascent and descent? Does the result look well? ISTR that
we need to handle the underline property specially due to these
considerations, so as to avoid producing broken underline.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76390
; Package
emacs
.
(Tue, 18 Feb 2025 15:41:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 76390 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Tue, 18 Feb 2025 11:41:26 +0100
>> From: Daniel Mendler via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> A few years ago there was a discussion on emacs-devel started by Jesse
>> Nazario about vertically centering text for line-spacing > 0. A patch
>> was provided back then by Jesse. I hope to revive the discussion and I
>> like to provide an updated patch.
>>
>> Centering text would be particularly useful if the text has a background
>> color (e.g., hl-line or hi-lock) as demonstrated by the following steps:
>>
>> 1. (setq-local line-spacing 0.5)
>> 2. (hl-line-mode 1)
>> 3. M-x hi-lock-face-symbol-at-point on a symbol at point
>>
>> The proposal was to add a new variable `line-spacing-vertical-center' to
>> enable text centering. Maybe it makes sense to use a more general
>> approach which allows finer control over the alignment, e.g., a variable
>> `line-spacing-align' which can be set to a floating point number in the
>> interval [0.0, 1.0]. The value 0.5 means to center the text, 0.0 means
>> to align the text at the top of the line and 1.0 means to align the text
>> at the bottom of the line. Fine control over the alignment allows to to
>> adjust to fine differences of the font and its baseline alignment.
>
> Rather than introducing yet another buffer-local knob, I think I'd
> prefer extending line-spacing to have a cons cell value (with car
> applied to ascent and cdr to descent). This will probably need to add
> a new field to the iterator struct.
Sounds good. A cons cell for line spacing (ascent . descent) would work.
However there is a small concern regarding backward compatibility since
some code may expect line-spacing to be only a number or nil. However
packages can also be updated and I doubt that there are many which are
affected.
> Also, we should support the same extension for the line-spacing
> property on the newline ending a line (see the node "Line Height" in
> the ELisp manual).
Agree.
> And finally, I have a question: what does this patch do with a line
> that mixes different fonts, especially fonts with very different
> values of ascent and descent? Does the result look well? ISTR that
> we need to handle the underline property specially due to these
> considerations, so as to avoid producing broken underline.
I cannot tell yet. I can answer that when I worked a little bit on the
patch. All I can say confidently is that the status quo with the
non-centered line-spacing does not look good, not even with a single
font (see my hi-lock example from above). I am sure that we can do
better in all cases; with a single font or with multiple fonts of
different height.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76390
; Package
emacs
.
(Tue, 18 Feb 2025 17:03:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 76390 <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: 76390 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> Date: Tue, 18 Feb 2025 16:40:15 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > And finally, I have a question: what does this patch do with a line
> > that mixes different fonts, especially fonts with very different
> > values of ascent and descent? Does the result look well? ISTR that
> > we need to handle the underline property specially due to these
> > considerations, so as to avoid producing broken underline.
>
> I cannot tell yet. I can answer that when I worked a little bit on the
> patch. All I can say confidently is that the status quo with the
> non-centered line-spacing does not look good, not even with a single
> font (see my hi-lock example from above).
"Good" in that case is in the eyes of the beholder, because the added
spacing is uniform whatever the font. You say "not good" because I'm
guessing you don't like the effect in general, not because it breaks
when different fonts are used on the same screen line.
> I am sure that we can do better in all cases; with a single font or
> with multiple fonts of different height.
The problem is that if we need to do something with different fonts,
it might be impossible to do that in the place in code where the patch
makes the changes. Cf what we do with the underline property.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76390
; Package
emacs
.
(Tue, 18 Feb 2025 18:05:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 76390 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> Cc: 76390 <at> debbugs.gnu.org, stefankangas <at> gmail.com
>> Date: Tue, 18 Feb 2025 16:40:15 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > And finally, I have a question: what does this patch do with a line
>> > that mixes different fonts, especially fonts with very different
>> > values of ascent and descent? Does the result look well? ISTR that
>> > we need to handle the underline property specially due to these
>> > considerations, so as to avoid producing broken underline.
>>
>> I cannot tell yet. I can answer that when I worked a little bit on the
>> patch. All I can say confidently is that the status quo with the
>> non-centered line-spacing does not look good, not even with a single
>> font (see my hi-lock example from above).
>
> "Good" in that case is in the eyes of the beholder, because the added
> spacing is uniform whatever the font. You say "not good" because I'm
> guessing you don't like the effect in general, not because it breaks
> when different fonts are used on the same screen line.
Yes, it depends on preference. Therefore I am suggesting to add a
customization option, e.g., `line-spacing-align', or alternatively
extend the `line-spacing' variable as you suggested, such that the
feature must be enabled explicitly.
I rarely use multiple fonts on a single line. But I agree that multiple
fonts should be supported well if a `line-spacing-align' patch gets
merged, given that some themes use fonts instead of colors for font
locking. Stefan Monnier mentioned this in the thread about adding new
semantic faces.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76390
; Package
emacs
.
(Tue, 18 Feb 2025 20:14:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 76390 <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: 76390 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> Date: Tue, 18 Feb 2025 19:04:07 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > "Good" in that case is in the eyes of the beholder, because the added
> > spacing is uniform whatever the font. You say "not good" because I'm
> > guessing you don't like the effect in general, not because it breaks
> > when different fonts are used on the same screen line.
>
> Yes, it depends on preference. Therefore I am suggesting to add a
> customization option, e.g., `line-spacing-align', or alternatively
> extend the `line-spacing' variable as you suggested, such that the
> feature must be enabled explicitly.
IMO, that'd be the wrong way of adding this feature. We already have
two variables (and the corresponding properties) that determine the
line height. Adding yet another one to them will make this
unnecessarily complicated. The fact that this new option will have no
effect unless line-spacing is non-nil doesn't help.
> I rarely use multiple fonts on a single line.
I think you underestimate how frequently this happens in routine usage
of Emacs. For example, any Info manual uses different fonts on the
same line, and so do *Help* buffers where they show key bindings.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76390
; Package
emacs
.
(Tue, 18 Feb 2025 20:34:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 76390 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I rarely use multiple fonts on a single line.
>
> I think you underestimate how frequently this happens in routine usage
> of Emacs. For example, any Info manual uses different fonts on the
> same line, and so do *Help* buffers where they show key bindings.
I don't see different fonts in Info or Help in my Emacs setup, but
that's probably due to the theme. Key bindings and text uses the same
font. However I see different fonts in Eww for example.
Daniel
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 19 Feb 2025 02:07:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 114 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.