Subject: bug#76390: [PATCH] Center lines vertically with line-spacing-vertical-center

From: Eli Zaretskii <[email-masked]>
Date: Tue, 18 Feb 2025 17:13:48 +0200

> Cc: Stefan Kangas <[email-masked]>
> 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" <[email-masked]>
> 
> 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.