unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
@ 2021-05-04 15:57 Stefan Kangas
  2021-05-04 16:12 ` Óscar Fuentes
                   ` (3 more replies)
  0 siblings, 4 replies; 44+ messages in thread
From: Stefan Kangas @ 2021-05-04 15:57 UTC (permalink / raw)
  To: emacs-devel

In typography, it is well known that the line height (leading) should be
a bit larger than the font size to improve legibility.  The drawback of
a larger leading is that fewer lines of text are visible on the screen
at the same time.

Emacs by default uses a leading of the font size + a few pixels (the
`line-spacing' variable is 0).  Conventional wisdom seems to suggest
instead that 1.2em (where 1em is the font size) is often a good
choice.[1]  Other editors also tend to use a larger leading than us.[2]

I suggest that we increase the default value of `line-spacing' to
improve legibility.  I believe this would improve our OOTB experience
for the majority users and use-cases.  In cases where it doesn't, users
are still free to revert to whatever was there before.

Below are the three options that I suggest we consider.  Note that "If
[the] value [of `line-spacing'] is a floating point number, it specifies
the spacing relative to the default frame line height."

[I've included line numbers below for the three options on my screen and
font size, but obviously YMMV.]

A. Ideally, we would use 0.15 for maximum legibility.  This is close to
   1.2 em. [53 lines, 11.6 % fewer lines]

B. We could also consider 0.10 to be more cautious. [56 lines, 6.66 %]

C. A very conservative option is to use 0.05, which would be a small
   incremental improvement on what we already have. [58 lines, 3.33 %]

D. The default. [60 lines, 0.0 %]

All in all, I think option B would be best, as that means we lose very
few lines on the screen (6 %).  Alternatively, we could pick option C,
which loses even fewer (3 %).

The way I suggest we carry this out is an experiment on master for 30
days, similarly to how we recently did with unbinding `M-o'.  This would
allow us to gather feedback and see how well this works in practice.

Footnotes:
[1] See also this link for reference:
    https://ux.stackexchange.com/questions/35270/is-there-an-optimal-font-size-line-height-ratio

[2]  See screenshots from some common editors here:

     VSCode
     https://user-images.githubusercontent.com/1487073/58344409-70473b80-7e0a-11e9-8570-b2efc6f8fa44.png

     Atom
     https://upload.wikimedia.org/wikipedia/commons/5/5f/Atom_screenshot_v1.41.0.png

     GEdit
     https://upload.wikimedia.org/wikipedia/commons/3/3f/Gedit.png



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-04 15:57 Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal] Stefan Kangas
@ 2021-05-04 16:12 ` Óscar Fuentes
  2021-05-04 16:59   ` Jim Porter
  2021-05-04 16:18 ` Eli Zaretskii
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 44+ messages in thread
From: Óscar Fuentes @ 2021-05-04 16:12 UTC (permalink / raw)
  To: emacs-devel

Stefan Kangas <stefan@marxist.se> writes:

> The way I suggest we carry this out is an experiment on master for 30
> days, similarly to how we recently did with unbinding `M-o'.  This would
> allow us to gather feedback and see how well this works in practice.

FWIW, I just tried both 0.15 and 0.10 and IMO it improves readability.
There are some negative consequences, though, like the "line" of
display-fill-column-indicator-mode losing any apparience of continuity.




^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-04 15:57 Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal] Stefan Kangas
  2021-05-04 16:12 ` Óscar Fuentes
@ 2021-05-04 16:18 ` Eli Zaretskii
  2021-05-04 21:29   ` Stefan Kangas
  2021-05-05  5:14 ` Richard Stallman
  2021-05-05 12:18 ` Daniele Nicolodi
  3 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-04 16:18 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: emacs-devel

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 4 May 2021 10:57:51 -0500
> 
> Emacs by default uses a leading of the font size + a few pixels (the
> `line-spacing' variable is 0).

I don't understand this (or disagree): AFAIU, by default line-spacing
is strictly zero, and we don't add anything to the font size.  If you
see something else in the code, can you point me to the code which I'm
missing, and which implements that default line-spacing?



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-04 16:12 ` Óscar Fuentes
@ 2021-05-04 16:59   ` Jim Porter
  2021-05-05  7:08     ` Augusto Stoffel
  2021-05-06 20:21     ` Stefan Kangas
  0 siblings, 2 replies; 44+ messages in thread
From: Jim Porter @ 2021-05-04 16:59 UTC (permalink / raw)
  To: emacs-devel

On 5/4/2021 9:12 AM, Óscar Fuentes wrote:
> Stefan Kangas <stefan@marxist.se> writes:
> 
>> The way I suggest we carry this out is an experiment on master for 30
>> days, similarly to how we recently did with unbinding `M-o'.  This would
>> allow us to gather feedback and see how well this works in practice.
> 
> FWIW, I just tried both 0.15 and 0.10 and IMO it improves readability.
> There are some negative consequences, though, like the "line" of
> display-fill-column-indicator-mode losing any apparience of continuity.

I'm not sure if there's an easy way to ensure the fill line looks 
continuous in this case, but if that could be improved, it would help in 
a few other areas even if line-spacing weren't increased. For example, 
with `org-prettify-entities' set to t, subscripts add a bit to the line 
height, causing the fill line to appear discontinuous. Likewise, I 
believe overlines add a bit to the line height too.

- Jim




^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-04 16:18 ` Eli Zaretskii
@ 2021-05-04 21:29   ` Stefan Kangas
  2021-05-05  2:28     ` Eli Zaretskii
  0 siblings, 1 reply; 44+ messages in thread
From: Stefan Kangas @ 2021-05-04 21:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> Emacs by default uses a leading of the font size + a few pixels (the
>> `line-spacing' variable is 0).
>
> I don't understand this (or disagree): AFAIU, by default line-spacing
> is strictly zero, and we don't add anything to the font size.  If you
> see something else in the code, can you point me to the code which I'm
> missing, and which implements that default line-spacing?

This is not based on any reading of the code, but merely a casual
observation based on what I see when I look at my screen: there are a
couple of pixels between characters (glyphs) on different rows.  If you
say that there is nothing extra added in addition to the font size, then
that is how it is.

Sorry if I caused any confusion by being unclear.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-04 21:29   ` Stefan Kangas
@ 2021-05-05  2:28     ` Eli Zaretskii
  0 siblings, 0 replies; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-05  2:28 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: emacs-devel

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 4 May 2021 16:29:03 -0500
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Emacs by default uses a leading of the font size + a few pixels (the
> >> `line-spacing' variable is 0).
> >
> > I don't understand this (or disagree): AFAIU, by default line-spacing
> > is strictly zero, and we don't add anything to the font size.  If you
> > see something else in the code, can you point me to the code which I'm
> > missing, and which implements that default line-spacing?
> 
> This is not based on any reading of the code, but merely a casual
> observation based on what I see when I look at my screen: there are a
> couple of pixels between characters (glyphs) on different rows.  If you
> say that there is nothing extra added in addition to the font size, then
> that is how it is.

We add nothing by default.  The height of each screen line is just the
maximum value of the sum of the glyph ascents and glyph descents on
that line.

If you move the cursor between two screen lines, you should see that
the cursor on line N ends exactly where the cursor on line N+1
begins.  Since the cursor's height is exactly the height of the screen
line, that confirms what I see in the code.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-04 15:57 Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal] Stefan Kangas
  2021-05-04 16:12 ` Óscar Fuentes
  2021-05-04 16:18 ` Eli Zaretskii
@ 2021-05-05  5:14 ` Richard Stallman
  2021-05-05 19:16   ` Stefan Kangas
  2021-05-05 12:18 ` Daniele Nicolodi
  3 siblings, 1 reply; 44+ messages in thread
From: Richard Stallman @ 2021-05-05  5:14 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think this change might be appreciated by most users, but perhaps we
should accompany it by an self-evident graphic UI for changing the
setting.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-04 16:59   ` Jim Porter
@ 2021-05-05  7:08     ` Augusto Stoffel
  2021-05-05  8:51       ` Daniel Mendler
  2021-05-05 19:47       ` Stefan Kangas
  2021-05-06 20:21     ` Stefan Kangas
  1 sibling, 2 replies; 44+ messages in thread
From: Augusto Stoffel @ 2021-05-05  7:08 UTC (permalink / raw)
  To: Jim Porter; +Cc: emacs-devel

On Tue,  4 May 2021 at 09:59, Jim Porter <jporterbugs@gmail.com> wrote:

In general, all ASCII art using box-drawing characters will look wrong
if line spacing is used.

In normal typography you are free to choose how much space to add
between lines, but the horizontal condensedness is a fixed
characteristic of the font.  It seems to me that for monospaced fonts
the vertical condensedness is pretty much fixed by the font design as
well.

For instance, in monospaced fonts the descender of "g" tends to look a
bit squished.  This is a compromise; if the font designer wanted to make
the font vertically more sparse, they might as well have given the
descender a bit more room.

> On 5/4/2021 9:12 AM, Óscar Fuentes wrote:
>> Stefan Kangas <stefan@marxist.se> writes:
>> 
>>> The way I suggest we carry this out is an experiment on master for 30
>>> days, similarly to how we recently did with unbinding `M-o'.  This would
>>> allow us to gather feedback and see how well this works in practice.
>> FWIW, I just tried both 0.15 and 0.10 and IMO it improves
>> readability.
>> There are some negative consequences, though, like the "line" of
>> display-fill-column-indicator-mode losing any apparience of continuity.
>
> I'm not sure if there's an easy way to ensure the fill line looks
> continuous in this case, but if that could be improved, it would help
> in a few other areas even if line-spacing weren't increased. For
> example, with `org-prettify-entities' set to t, subscripts add a bit
> to the line height, causing the fill line to appear
> discontinuous. Likewise, I believe overlines add a bit to the line
> height too.
>
> - Jim



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-05  7:08     ` Augusto Stoffel
@ 2021-05-05  8:51       ` Daniel Mendler
  2021-05-05 19:47       ` Stefan Kangas
  1 sibling, 0 replies; 44+ messages in thread
From: Daniel Mendler @ 2021-05-05  8:51 UTC (permalink / raw)
  To: Augusto Stoffel, Jim Porter; +Cc: emacs-devel

On 5/5/21 9:08 AM, Augusto Stoffel wrote:
> In general, all ASCII art using box-drawing characters will look wrong
> if line spacing is used.
> 
> In normal typography you are free to choose how much space to add
> between lines, but the horizontal condensedness is a fixed
> characteristic of the font.  It seems to me that for monospaced fonts
> the vertical condensedness is pretty much fixed by the font design as
> well.
> 
> For instance, in monospaced fonts the descender of "g" tends to look a
> bit squished.  This is a compromise; if the font designer wanted to make
> the font vertically more sparse, they might as well have given the
> descender a bit more room.

This is true, however my experiments to use ASCII box drawing characters
for UI elements were all quite unsuccessful recently (UI popup in Corfu
and various UI tricks in Consult). Furthermore if you implement a UI you
should make sure that it works well with line-spacing>0.

I have now set line-spacing=0.1 in my configuration and I like it so
far. It looks better indeed. I don't see something in wrong in testing
this for a while in order to obtain user feedback.

Daniel



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-04 15:57 Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal] Stefan Kangas
                   ` (2 preceding siblings ...)
  2021-05-05  5:14 ` Richard Stallman
@ 2021-05-05 12:18 ` Daniele Nicolodi
  2021-05-05 19:17   ` Stefan Kangas
  3 siblings, 1 reply; 44+ messages in thread
From: Daniele Nicolodi @ 2021-05-05 12:18 UTC (permalink / raw)
  To: emacs-devel

On 04/05/2021 17:57, Stefan Kangas wrote:
> C. A very conservative option is to use 0.05, which would be a small
>    incremental improvement on what we already have. [58 lines, 3.33 %]
> 
> D. The default. [60 lines, 0.0 %]
On my system (macOS, Emacs 27.2 from https://emacsformacosx.com/) with
some fonts, these two settings produce the same result. It seems that
the "resolution" for this setting is 0.1 (thus 0.5 is rounded to 0.0).

In general, the visual distance between lines depends on the font: with
some fonts I use a line-spacing of 0.0, while others require setting
line-spacing to 0.15 to obtain roughly the same distance.

Cheers,
Dan



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-05  5:14 ` Richard Stallman
@ 2021-05-05 19:16   ` Stefan Kangas
  2021-05-06 20:21     ` Stefan Kangas
  0 siblings, 1 reply; 44+ messages in thread
From: Stefan Kangas @ 2021-05-05 19:16 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

Richard Stallman <rms@gnu.org> writes:

> I think this change might be appreciated by most users, but perhaps we
> should accompany it by an self-evident graphic UI for changing the
> setting.

Adding it to the "Options" menu, perhaps?

Maybe that could be a good idea whether or not we change anything else?



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-05 12:18 ` Daniele Nicolodi
@ 2021-05-05 19:17   ` Stefan Kangas
  0 siblings, 0 replies; 44+ messages in thread
From: Stefan Kangas @ 2021-05-05 19:17 UTC (permalink / raw)
  To: Daniele Nicolodi, emacs-devel

Daniele Nicolodi <daniele@grinta.net> writes:

>> C. A very conservative option is to use 0.05, which would be a small
>>    incremental improvement on what we already have. [58 lines, 3.33 %]
>>
>> D. The default. [60 lines, 0.0 %]
>
> On my system (macOS, Emacs 27.2 from https://emacsformacosx.com/) with
> some fonts, these two settings produce the same result. It seems that
> the "resolution" for this setting is 0.1 (thus 0.5 is rounded to 0.0).

I tested this on my macOS machine with a build from Homebrew, and one
built from the master branch.  In both these builds, 0.0 and 0.05 are
the same.  (0.1 and 0.15 are different, though.)

So I guess for this to matter on macOS, we would need to change this to
at least 0.1.

> In general, the visual distance between lines depends on the font: with
> some fonts I use a line-spacing of 0.0, while others require setting
> line-spacing to 0.15 to obtain roughly the same distance.

Yes, this will depend on the font.

Properly speaking, choosing the value should be a manual endeavor.  But
I don't think this is something we can easily do in Emacs as things
stand.  We would first need to build some infrastructure to change line
spacing depending on the font used.

Barring that, the best we can do is to find some happy average that
works okay most of the time.

    A true ideal line-height doesn’t exist, because every type-
    face is different.  You need to take into account the design of the
    typeface as well as the typesetting.  Is this a wide or decorative
    typeface?  You may need more space between lines to let the
    details breathe.  Is this a narrow text column, as you might see in
    hanging captions in an article’s margins?  You could use a smaller
    type size and keep the line-height tighter than the article text
    next to the caption.  By observing these factors, you can judge
    what a particular setting requires.

    A good starting point with line-height is about 1.2–1.8 ... It
    takes some trial and error to see what’s right for a given typeface
    at a given size in a given situation.  I find it useful to declare a
    line-height and see how it feels to read text at that setting.  Do
    letter ascenders and descenders crash into one another or run a
    little too close between lines? If so, more line-height is
    needed.  Are the spaces between the lines more prominent than the
    lines themselves?  If so, try reducing the line-height.  When you
    find an appropriate line-height, the text will seem to fall into a
    natural rhythm, feeling neither too far apart nor too close.

    - "On Web Typography", Jason Santa Maria, A Book Apart, 2014.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-05  7:08     ` Augusto Stoffel
  2021-05-05  8:51       ` Daniel Mendler
@ 2021-05-05 19:47       ` Stefan Kangas
  2021-05-06  9:26         ` Augusto Stoffel
  1 sibling, 1 reply; 44+ messages in thread
From: Stefan Kangas @ 2021-05-05 19:47 UTC (permalink / raw)
  To: Augusto Stoffel, Jim Porter; +Cc: emacs-devel

Augusto Stoffel <arstoffel@gmail.com> writes:

> In normal typography you are free to choose how much space to add
> between lines, but the horizontal condensedness is a fixed
> characteristic of the font.

In a sense, you are free to choose vertical spacing however you want.
But a lot of time and effort has been invested into figuring out how to
choose line height (leading) wisely.  It is generally a good idea to try
to adhere to such best practices.

In body text, horizontal spacing is generally determined by the typeface
itself.  However, in certain situations we do need to use kerning, and
even tracking (letter-spacing).  So I don't exactly understand why you
consider this more of a "fixed characteristic" than vertical spacing.

For me it is almost the other way around: you set the line height
(leading) depending on variables such as the x-height of the font,
column width, etc.  And then you tend to never change it anywhere in the
document (book, website, etc.).  Whereas the horizontal spacing might
indeed vary in different paragraphs and lines.

(In print production, it is very common to change the letter-spacing
(tracking) by as much as 10 % in an entire paragraph, for example to
avoid "widows" in a book.  For small caps the guidelines of one large
publishing house that I've read recommends 60 % tracking as a
*minimum*.)

> It seems to me that for monospaced fonts the vertical condensedness is
> pretty much fixed by the font design as well.
>
> For instance, in monospaced fonts the descender of "g" tends to look a
> bit squished.  This is a compromise; if the font designer wanted to make
> the font vertically more sparse, they might as well have given the
> descender a bit more room.

I agree that monospaced fonts are often designed to work even in
situations where there is no extra leading.  That doesn't mean that this
is the optimal choice for such fonts.

A font designer does determine the x-height of the font, but this is not
the only variable in putting characters on screen.  Whoever does the
final design will still have to chose the line height.

Here is a long quote from /The Elements of Typographic Style/ by Robert
Bringhurst, as food for thought:

    2.2.1 Choose a basic leading that suits the typeface, text and
    measure.

    Time is divisible into any number of increments.  So is space.
    But for working purposes, time in music is divided into a few
    proportional intervals: halves, quarters, eighths, sixteenths and so
    on.  And time in most music is measured.  Add a quarter note to a
    bar whose time is already accounted for and, somewhere nearby,
    the equivalent of that quarter note must come out.  Phrasing and
    rhythm can move in and out of phase - as they do in the singing
    of Billie Holiday and the trumpet solos of Miles Davis - but the
    force of blues phrasing and syncopation vanishes if the beat is
    actually lost.

    Space in typography is like time in music.  It is infinitely
    divisible, but a few proportional intervals can be much more useful
    than a limitless choice of arbitrary quantities.  The metering of
    horizontal space is accomplished almost unconsciously in typography.
    You choose and prepare a font, and you choose a measure (the width
    of the column).  When you set the type, the measure fills with the
    varied rhythm of repeating letter shapes, which are music to the
    eye.  Vertical space is metered in a different way.  You must choose
    not only the overall measure - the depth of the column or page - but
    also a basic rhythmical unit.  This unit is the leading, which is the
    distance from one baseline to the next.

    Eleven-point type set solid is described as 11/11.  The theoretical
    face of the type is 11 points high (from the top of d to the bottom
    of p, if the type is full on the body), and the distance from the
    baseline of line one to the baseline of line two is also 11
    points.  Add two points of lead (interlinear space), and the type is
    set 11/13.  The type size has not changed, but the distance from
    baseline to baseline has increased to 13 points, and the type has
    more room to breathe.

    The text of the book you are reading, to take an example, is
    set 10/12 x 21.  This means that the type size is 10 pt, the added
    lead is 2 pt, giving a total leading of 12 pt, and the line length is
    21 picas.

    Continuous text is very rarely set with negative leading, and only a
    few text faces read well when set solid.  Most text requires
    positive leading.  Settings such as 9/11, 10/12, 11/13 and 12/15 are
    routine.  Longer measures need more lead than short ones.  Dark
    faces need more lead than light ones.  Large-bodied faces need more
    lead than smaller-bodied ones.  Faces like Bauer Bodoni, with
    substantial color and a rigid vertical axis, need much more lead
    than faces like Bembo, whose color is light and whose axis is based
    on the writing hand.  And unserifed faces often need more lead (or a
    shorter line) than their serifed counterparts. Extra leading is also
    generally welcome where the text is thickened by superscripts,
    subscripts, mathematical expressions, or the frequent use of full
    capitals.  A text in German would ideally have a little more lead
    than the same text in Latin or French, purely because of the
    increased frequency of capitals.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-05 19:47       ` Stefan Kangas
@ 2021-05-06  9:26         ` Augusto Stoffel
  2021-05-06 10:10           ` Eli Zaretskii
  2021-05-06 20:22           ` Stefan Kangas
  0 siblings, 2 replies; 44+ messages in thread
From: Augusto Stoffel @ 2021-05-06  9:26 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Jim Porter, emacs-devel

On Wed,  5 May 2021 at 14:47, Stefan Kangas <stefankangas@gmail.com> wrote:

> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>> In normal typography you are free to choose how much space to add
>> between lines, but the horizontal condensedness is a fixed
>> characteristic of the font.
>
> In a sense, you are free to choose vertical spacing however you want.
> But a lot of time and effort has been invested into figuring out how to
> choose line height (leading) wisely.  It is generally a good idea to try
> to adhere to such best practices.

Comparing the picture in [1] and what I see if I put the block cursor
over an "H", I conclude that monospaced fonts come with some built-in
leading.  In other words, they are "bastard fonts" [2], and a nil for
`line-spacing' doesn't mean "solid" typesetting.

Does that mean the built-in leading is optimal, or a good default?  Not
necessarily, of course.

I wrote mostly to point out that changing the line spacing breaks any
fancy box-drawing.  I'm not claiming this is more important than the
other considerations you made, by the way.

[1]: https://en.wikipedia.org/wiki/Body_height_(typography)
[2]: https://en.wikipedia.org/wiki/Leading#Bastard_fonts

> In body text, horizontal spacing is generally determined by the typeface
> itself.  However, in certain situations we do need to use kerning, and
> even tracking (letter-spacing).  So I don't exactly understand why you
> consider this more of a "fixed characteristic" than vertical spacing.

Kerning, tracking and other forms of microtypography are case-by-case
adjustments, intended to be basically subliminal, so I'd say yes, the
overall condensedness is pretty much a fixed characteristic of the font.
And these things are out of reach for Emacs anyway.

Leading is a global, visible design choice.  That's why I made the
distinction.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06  9:26         ` Augusto Stoffel
@ 2021-05-06 10:10           ` Eli Zaretskii
  2021-05-06 11:47             ` Augusto Stoffel
  2021-05-06 20:22           ` Stefan Kangas
  1 sibling, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-06 10:10 UTC (permalink / raw)
  To: Augusto Stoffel; +Cc: jporterbugs, stefankangas, emacs-devel

> From: Augusto Stoffel <arstoffel@gmail.com>
> Date: Thu, 06 May 2021 11:26:45 +0200
> Cc: Jim Porter <jporterbugs@gmail.com>, emacs-devel@gnu.org
> 
> Comparing the picture in [1] and what I see if I put the block cursor
> over an "H", I conclude that monospaced fonts come with some built-in
> leading.  In other words, they are "bastard fonts" [2], and a nil for
> `line-spacing' doesn't mean "solid" typesetting.

I don't think this is true.  First, what you cite refers to so-called
"manual typesetting", not to digital typography.  And second, the
monospaced fonts we use define ascent and descent for each glyph, and
we use that and nothing else (unless the font is broken, in which case
we have fallbacks in place, but that's not relevant to the issue at
hand).  AFAIU, the ascent and descent of each font glyph in a
monospaced font is set up such that they accommodate both the tallest
glyph and the lowest one.  Perhaps that is why you think they have
some "leading", because you probably didn't examine all of the font's
glyphs (we generally use as default fonts that cover many popular
scripts).

> Kerning, tracking and other forms of microtypography are case-by-case
> adjustments, intended to be basically subliminal, so I'd say yes, the
> overall condensedness is pretty much a fixed characteristic of the font.
> And these things are out of reach for Emacs anyway.

They are not out of reach for us, because the shaping engine(s) we use
know how to apply these features.  We just don't use them by default
with most characters, that's all: we don't ask the text-shaping engine
how to render each sequence of characters we need to display, we only
ask it about some relatively rare sequences.  The reason for that is
that under the current design of the display engine, calling the
shaping engine is very expensive, as it requires calling out to Lisp,
which then calls back into C.  So we only do that when necessary.  But
a Lisp program can change that.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 10:10           ` Eli Zaretskii
@ 2021-05-06 11:47             ` Augusto Stoffel
  2021-05-06 11:57               ` Eli Zaretskii
  0 siblings, 1 reply; 44+ messages in thread
From: Augusto Stoffel @ 2021-05-06 11:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jporterbugs, stefankangas, emacs-devel

On Thu,  6 May 2021 at 13:10, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Augusto Stoffel <arstoffel@gmail.com>
>> Date: Thu, 06 May 2021 11:26:45 +0200
>> Cc: Jim Porter <jporterbugs@gmail.com>, emacs-devel@gnu.org
>> 
>> Comparing the picture in [1] and what I see if I put the block cursor
>> over an "H", I conclude that monospaced fonts come with some built-in
>> leading.  In other words, they are "bastard fonts" [2], and a nil for
>> `line-spacing' doesn't mean "solid" typesetting.
>
> I don't think this is true.  First, what you cite refers to so-called
> "manual typesetting", not to digital typography.  And second, the
> monospaced fonts we use define ascent and descent for each glyph, and
> we use that and nothing else (unless the font is broken, in which case
> we have fallbacks in place, but that's not relevant to the issue at
> hand).  AFAIU, the ascent and descent of each font glyph in a
> monospaced font is set up such that they accommodate both the tallest
> glyph and the lowest one.  Perhaps that is why you think they have
> some "leading", because you probably didn't examine all of the font's
> glyphs (we generally use as default fonts that cover many popular
> scripts).

Okay, we could ask a font designer if this standard glyph size is chosen
so as to provide a reasonable default leading (as I was assuming), or
merely to fit the ascent and descent of the tallest/deepest glyphs.  But
I would bet that the answer is both, since designing a font, especially
monospaced, involves lots of compromises.

Anyway, I think we can agree that setting `line-spacing' to nil is *not*
analogous setting \baselineskip=0pt in TeX.  That's all I wanted to
say there.

>> Kerning, tracking and other forms of microtypography are case-by-case
>> adjustments, intended to be basically subliminal, so I'd say yes, the
>> overall condensedness is pretty much a fixed characteristic of the font.
>> And these things are out of reach for Emacs anyway.
>
> They are not out of reach for us, because the shaping engine(s) we use
> know how to apply these features.  We just don't use them by default
> with most characters, that's all: we don't ask the text-shaping engine
> how to render each sequence of characters we need to display, we only
> ask it about some relatively rare sequences.  The reason for that is
> that under the current design of the display engine, calling the
> shaping engine is very expensive, as it requires calling out to Lisp,
> which then calls back into C.  So we only do that when necessary.  But
> a Lisp program can change that.

You are right, I should have said "these things [such as kerning] are
not relevant for monospaced fonts".



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 11:47             ` Augusto Stoffel
@ 2021-05-06 11:57               ` Eli Zaretskii
  2021-05-06 12:27                 ` Augusto Stoffel
  2021-05-06 12:30                 ` Gregory Heytings
  0 siblings, 2 replies; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-06 11:57 UTC (permalink / raw)
  To: Augusto Stoffel; +Cc: jporterbugs, stefankangas, emacs-devel

> From: Augusto Stoffel <arstoffel@gmail.com>
> Cc: stefankangas@gmail.com,  jporterbugs@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 06 May 2021 13:47:56 +0200
> 
> Anyway, I think we can agree that setting `line-spacing' to nil is *not*
> analogous setting \baselineskip=0pt in TeX.

I'm TeX-illiterate.  Can you explain why these two aren't analogous?
It sounds like they are, when I read the definition of what
\baselineskip=0pt does.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 11:57               ` Eli Zaretskii
@ 2021-05-06 12:27                 ` Augusto Stoffel
  2021-05-06 15:21                   ` Eli Zaretskii
  2021-05-06 12:30                 ` Gregory Heytings
  1 sibling, 1 reply; 44+ messages in thread
From: Augusto Stoffel @ 2021-05-06 12:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jporterbugs, stefankangas, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

On Thu,  6 May 2021 at 14:57, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Augusto Stoffel <arstoffel@gmail.com>
>> Cc: stefankangas@gmail.com,  jporterbugs@gmail.com,  emacs-devel@gnu.org
>> Date: Thu, 06 May 2021 13:47:56 +0200
>> 
>> Anyway, I think we can agree that setting `line-spacing' to nil is *not*
>> analogous setting \baselineskip=0pt in TeX.
>
> I'm TeX-illiterate.  Can you explain why these two aren't analogous?
> It sounds like they are, when I read the definition of what
> \baselineskip=0pt does.

\baselineskip=0pt and (setq line-spacing nil) both mean to typeset lines
as close as possible, without overlapping bounding boxes.  But the
achieved effect is very different, because "source code typography" and
"manual typography" are very different.

I've attached a PDF where the first page uses the default \baselineskip,
the second sets it to zero.  Which one looks more like emacs -Q?


[-- Attachment #2: x.pdf --]
[-- Type: application/pdf, Size: 20394 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 11:57               ` Eli Zaretskii
  2021-05-06 12:27                 ` Augusto Stoffel
@ 2021-05-06 12:30                 ` Gregory Heytings
  2021-05-06 15:22                   ` Eli Zaretskii
  1 sibling, 1 reply; 44+ messages in thread
From: Gregory Heytings @ 2021-05-06 12:30 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jporterbugs, Augusto Stoffel, stefankangas, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]


>> Anyway, I think we can agree that setting `line-spacing' to nil is 
>> *not* analogous setting \baselineskip=0pt in TeX.
>
> I'm TeX-illiterate.  Can you explain why these two aren't analogous? It 
> sounds like they are, when I read the definition of what 
> \baselineskip=0pt does.
>

\baselineskip=0pt means that the height and depth of a text line is equal 
to the maximal height and depth of the characters in that line.  See the 
attached two screenshots that demonstrate the difference.

[-- Attachment #2: Type: image/png, Size: 2996 bytes --]

[-- Attachment #3: Type: image/png, Size: 3836 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 12:27                 ` Augusto Stoffel
@ 2021-05-06 15:21                   ` Eli Zaretskii
  2021-05-06 15:46                     ` Augusto Stoffel
  0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-06 15:21 UTC (permalink / raw)
  To: Augusto Stoffel; +Cc: jporterbugs, stefankangas, emacs-devel

> From: Augusto Stoffel <arstoffel@gmail.com>
> Cc: stefankangas@gmail.com,  jporterbugs@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 06 May 2021 14:27:23 +0200
> 
> I've attached a PDF where the first page uses the default \baselineskip,
> the second sets it to zero.  Which one looks more like emacs -Q?

I only see a difference in the lines that are all dots.  Did I miss
something?



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 12:30                 ` Gregory Heytings
@ 2021-05-06 15:22                   ` Eli Zaretskii
  2021-05-06 16:21                     ` Gregory Heytings
  0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-06 15:22 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: jporterbugs, arstoffel, stefankangas, emacs-devel

> Date: Thu, 06 May 2021 12:30:23 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Augusto Stoffel <arstoffel@gmail.com>, jporterbugs@gmail.com, 
>     stefankangas@gmail.com, emacs-devel@gnu.org
> 
> \baselineskip=0pt means that the height and depth of a text line is equal 
> to the maximal height and depth of the characters in that line.  See the 
> attached two screenshots that demonstrate the difference.

That's what Emacs does as well, when line-spacing is nil, but Augusto
says they are different.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 15:21                   ` Eli Zaretskii
@ 2021-05-06 15:46                     ` Augusto Stoffel
  2021-05-06 16:16                       ` Eli Zaretskii
  0 siblings, 1 reply; 44+ messages in thread
From: Augusto Stoffel @ 2021-05-06 15:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jporterbugs, stefankangas, emacs-devel

On Thu,  6 May 2021 at 18:21, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Augusto Stoffel <arstoffel@gmail.com>
>> Cc: stefankangas@gmail.com,  jporterbugs@gmail.com,  emacs-devel@gnu.org
>> Date: Thu, 06 May 2021 14:27:23 +0200
>> 
>> I've attached a PDF where the first page uses the default \baselineskip,
>> the second sets it to zero.  Which one looks more like emacs -Q?
>
> I only see a difference in the lines that are all dots.  Did I miss
> something?

Yes.  In the second page (\baselineskip=0pt), the text is very cramped
in the vertical direction.  Not pleasant to look at.  Also, much more
cramped than emacs -Q currently is if you use a reasonable font.  And
this is despite the fact that emacs -Q adds no extra space between
lines.

In the first page (default \baselineskip), the text is rather condensed
vertically, but not to a degree that it becomes unpleasant.  emacs -Q is
rather condensed vertically, but not to the degree of being unpleasant.
Paradoxically, TeX is using the equivalent of (setq line-spacing 0.2).

Now, this is an aesthetics question, therefore subjective — just like the
original subject of this thread.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 15:46                     ` Augusto Stoffel
@ 2021-05-06 16:16                       ` Eli Zaretskii
  0 siblings, 0 replies; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-06 16:16 UTC (permalink / raw)
  To: Augusto Stoffel; +Cc: jporterbugs, stefankangas, emacs-devel

> From: Augusto Stoffel <arstoffel@gmail.com>
> Cc: jporterbugs@gmail.com,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 06 May 2021 17:46:41 +0200
> 
> In the second page (\baselineskip=0pt), the text is very cramped
> in the vertical direction.  Not pleasant to look at.

I don't think I agree, so this seems like a matter of personal
preferences.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 15:22                   ` Eli Zaretskii
@ 2021-05-06 16:21                     ` Gregory Heytings
  2021-05-06 16:29                       ` Eli Zaretskii
  0 siblings, 1 reply; 44+ messages in thread
From: Gregory Heytings @ 2021-05-06 16:21 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jporterbugs, arstoffel, stefankangas, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]


>> \baselineskip=0pt means that the height and depth of a text line is 
>> equal to the maximal height and depth of the characters in that line. 
>> See the attached two screenshots that demonstrate the difference.
>
> That's what Emacs does as well, when line-spacing is nil, but Augusto 
> says they are different.
>

Unless I'm missing something, that's not what Emacs does, no.  I attach 
two screenshots of the exact same text with the exact same font, one with 
Emacs (setq line-spacing nil) and the other with TeX (\baselineskip=0pt). 
The effect is very different.

[-- Attachment #2: Type: image/png, Size: 1482 bytes --]

[-- Attachment #3: Type: image/png, Size: 1417 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 16:21                     ` Gregory Heytings
@ 2021-05-06 16:29                       ` Eli Zaretskii
  2021-05-06 16:57                         ` Daniele Nicolodi
  2021-05-06 17:01                         ` Gregory Heytings
  0 siblings, 2 replies; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-06 16:29 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: jporterbugs, arstoffel, stefankangas, emacs-devel

> Date: Thu, 06 May 2021 16:21:20 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: jporterbugs@gmail.com, arstoffel@gmail.com, stefankangas@gmail.com, 
>     emacs-devel@gnu.org
> 
> >> \baselineskip=0pt means that the height and depth of a text line is 
> >> equal to the maximal height and depth of the characters in that line. 
> >> See the attached two screenshots that demonstrate the difference.
> >
> > That's what Emacs does as well, when line-spacing is nil, but Augusto 
> > says they are different.
> 
> Unless I'm missing something, that's not what Emacs does, no.  I attach 
> two screenshots of the exact same text with the exact same font, one with 
> Emacs (setq line-spacing nil) and the other with TeX (\baselineskip=0pt). 
> The effect is very different.

Then your description of what TeX does is probably incomplete or
inaccurate.

on the Emacs side, I can point you to the code which implements
line-spacing, which clearly shows that if line-spacing is nil, the
default, we add NOTHING (a.k.a. "zero") to the height of the line,
leaving it at its computed value of the sum of the maximum ascent and
maximum descent of the glyphs in that line.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 16:29                       ` Eli Zaretskii
@ 2021-05-06 16:57                         ` Daniele Nicolodi
  2021-05-06 17:53                           ` Eli Zaretskii
  2021-05-06 17:01                         ` Gregory Heytings
  1 sibling, 1 reply; 44+ messages in thread
From: Daniele Nicolodi @ 2021-05-06 16:57 UTC (permalink / raw)
  To: emacs-devel

On 06/05/2021 18:29, Eli Zaretskii wrote:
>> Date: Thu, 06 May 2021 16:21:20 +0000
>> From: Gregory Heytings <gregory@heytings.org>
>> cc: jporterbugs@gmail.com, arstoffel@gmail.com, stefankangas@gmail.com, 
>>     emacs-devel@gnu.org
>>
>>>> \baselineskip=0pt means that the height and depth of a text line is 
>>>> equal to the maximal height and depth of the characters in that line. 
>>>> See the attached two screenshots that demonstrate the difference.
>>>
>>> That's what Emacs does as well, when line-spacing is nil, but Augusto 
>>> says they are different.
>>
>> Unless I'm missing something, that's not what Emacs does, no.  I attach 
>> two screenshots of the exact same text with the exact same font, one with 
>> Emacs (setq line-spacing nil) and the other with TeX (\baselineskip=0pt). 
>> The effect is very different.
> 
> Then your description of what TeX does is probably incomplete or
> inaccurate.
> 
> on the Emacs side, I can point you to the code which implements
> line-spacing, which clearly shows that if line-spacing is nil, the
> default, we add NOTHING (a.k.a. "zero") to the height of the line,
> leaving it at its computed value of the sum of the maximum ascent and
> maximum descent of the glyphs in that line.

I didn't look at the code, but I don't think this is true: on my Emacs,
lines containing only "." or containing only "l" have exactly the same
height, as I would expect. Also, lines containing only a new line
character (thus no printable characters) still have the same height as
lines with content, as expected.

Are you sure Emacs does not consider the maximum ascent and descent of
each _font_ contained in a line and not of each _glyph_?

Cheers,
Dan



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 16:29                       ` Eli Zaretskii
  2021-05-06 16:57                         ` Daniele Nicolodi
@ 2021-05-06 17:01                         ` Gregory Heytings
  2021-05-06 17:34                           ` Eli Zaretskii
  1 sibling, 1 reply; 44+ messages in thread
From: Gregory Heytings @ 2021-05-06 17:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jporterbugs, arstoffel, stefankangas, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]


>>>> \baselineskip=0pt means that the height and depth of a text line is 
>>>> equal to the maximal height and depth of the characters in that line. 
>>>> See the attached two screenshots that demonstrate the difference.
>>>
>>> That's what Emacs does as well, when line-spacing is nil, but Augusto 
>>> says they are different.
>>
>> Unless I'm missing something, that's not what Emacs does, no.  I attach 
>> two screenshots of the exact same text with the exact same font, one 
>> with Emacs (setq line-spacing nil) and the other with TeX 
>> (\baselineskip=0pt). The effect is very different.
>
> Then your description of what TeX does is probably incomplete or 
> inaccurate.
>

The TeXbook says: "Whenever a box is added to a vertical list [i.e., a 
line is added to a page under construction], TeX inserts "interline glue" 
intended to make the distance between the baseline of the new box and the 
baseline of the previous box exactly equal to the value of \baselineskip."

In more detail, the line-spacing algorithm also uses \lineskip, whose 
default value is 1pt.  If you set both \baselineskip and \lineskip to 0pt, 
there is no vertical space whatsoever between the lines, see the attached 
screenshot.

>
> on the Emacs side, I can point you to the code which implements 
> line-spacing, which clearly shows that if line-spacing is nil, the 
> default, we add NOTHING (a.k.a. "zero") to the height of the line, 
> leaving it at its computed value of the sum of the maximum ascent and 
> maximum descent of the glyphs in that line.
>

Of course I trust you.  Perhaps Emacs has a different understanding of 
what the ascent and descent of a glyph is?  Otherwise a line of dots would 
use less vertical space than a line of X's, which is what happens with TeX 
with \baselineskip=0pt and/or \lineskip=0pt.

Anyway, I'm not sure all this is really important for this discussion.

[-- Attachment #2: Type: image/png, Size: 1378 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 17:01                         ` Gregory Heytings
@ 2021-05-06 17:34                           ` Eli Zaretskii
  2021-05-06 18:15                             ` Gregory Heytings
  0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-06 17:34 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: jporterbugs, arstoffel, stefankangas, emacs-devel

> Date: Thu, 06 May 2021 17:01:36 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: jporterbugs@gmail.com, arstoffel@gmail.com, stefankangas@gmail.com, 
>     emacs-devel@gnu.org
> 
> > on the Emacs side, I can point you to the code which implements 
> > line-spacing, which clearly shows that if line-spacing is nil, the 
> > default, we add NOTHING (a.k.a. "zero") to the height of the line, 
> > leaving it at its computed value of the sum of the maximum ascent and 
> > maximum descent of the glyphs in that line.
> 
> Of course I trust you.  Perhaps Emacs has a different understanding of 
> what the ascent and descent of a glyph is?

We use the font's ascent and descent values, when a font provides them
and they are reasonable.  Maybe those values include some spacing?
I'm not an expert on fonts and typography, so I don't know.

> Anyway, I'm not sure all this is really important for this discussion.

Right.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 16:57                         ` Daniele Nicolodi
@ 2021-05-06 17:53                           ` Eli Zaretskii
  2021-05-06 17:57                             ` Eli Zaretskii
  2021-05-06 20:24                             ` Daniele Nicolodi
  0 siblings, 2 replies; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-06 17:53 UTC (permalink / raw)
  To: Daniele Nicolodi; +Cc: emacs-devel

> From: Daniele Nicolodi <daniele@grinta.net>
> Date: Thu, 6 May 2021 18:57:46 +0200
> 
> I didn't look at the code, but I don't think this is true: on my Emacs,
> lines containing only "." or containing only "l" have exactly the same
> height, as I would expect.

You assume that the metrics of these two glyphs are different in
monospaced fonts?

> Also, lines containing only a new line character (thus no printable
> characters) still have the same height as lines with content, as
> expected.

Newline leaves no glyphs on display, so their metrics cannot be
calculated from the font.

> Are you sure Emacs does not consider the maximum ascent and descent of
> each _font_ contained in a line and not of each _glyph_?

Why do you think there's a difference?



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 17:53                           ` Eli Zaretskii
@ 2021-05-06 17:57                             ` Eli Zaretskii
  2021-05-06 20:24                             ` Daniele Nicolodi
  1 sibling, 0 replies; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-06 17:57 UTC (permalink / raw)
  To: daniele, emacs-devel

> Date: Thu, 06 May 2021 20:53:31 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Daniele Nicolodi <daniele@grinta.net>
> > Date: Thu, 6 May 2021 18:57:46 +0200
> > 
> > I didn't look at the code, but I don't think this is true: on my Emacs,
> > lines containing only "." or containing only "l" have exactly the same
> > height, as I would expect.
> 
> You assume that the metrics of these two glyphs are different in
> monospaced fonts?
> 
> > Also, lines containing only a new line character (thus no printable
> > characters) still have the same height as lines with content, as
> > expected.
> 
> Newline leaves no glyphs on display, so their metrics cannot be
> calculated from the font.
> 
> > Are you sure Emacs does not consider the maximum ascent and descent of
> > each _font_ contained in a line and not of each _glyph_?
> 
> Why do you think there's a difference?

And in any case, line-spacing of nil adds nothing to the metrics, no
matter where they come from.  IOW, Emacs doesn't determine this; the
font does.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 17:34                           ` Eli Zaretskii
@ 2021-05-06 18:15                             ` Gregory Heytings
  0 siblings, 0 replies; 44+ messages in thread
From: Gregory Heytings @ 2021-05-06 18:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jporterbugs, arstoffel, stefankangas, emacs-devel


>> Of course I trust you.  Perhaps Emacs has a different understanding of 
>> what the ascent and descent of a glyph is?
>
> We use the font's ascent and descent values,
>

Unless that's a typo, that's the difference: Emacs uses the _font_ ascent 
and descent values, TeX uses the _individual character_ ascent and descent 
values.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-05 19:16   ` Stefan Kangas
@ 2021-05-06 20:21     ` Stefan Kangas
  2021-05-07  4:03       ` Eli Zaretskii
  0 siblings, 1 reply; 44+ messages in thread
From: Stefan Kangas @ 2021-05-06 20:21 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

Stefan Kangas <stefan@marxist.se> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> I think this change might be appreciated by most users, but perhaps we
>> should accompany it by an self-evident graphic UI for changing the
>> setting.
>
> Adding it to the "Options" menu, perhaps?
>
> Maybe that could be a good idea whether or not we change anything else?

I'm looking into adding this to the options menu, but would we want to
do this for the current buffer, globally, or both?

My current thinking is that a user might want both, but this would make
the menu too messy.  So perhaps we can get away with only supporting a
global setting from the menu.  That should be the most common use-case,
and if a user needs even more customization they will have to do it
"manually".



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-04 16:59   ` Jim Porter
  2021-05-05  7:08     ` Augusto Stoffel
@ 2021-05-06 20:21     ` Stefan Kangas
  2021-05-06 23:17       ` Jim Porter
  2021-05-07  4:05       ` Eli Zaretskii
  1 sibling, 2 replies; 44+ messages in thread
From: Stefan Kangas @ 2021-05-06 20:21 UTC (permalink / raw)
  To: Jim Porter, emacs-devel

Jim Porter <jporterbugs@gmail.com> writes:

> On 5/4/2021 9:12 AM, Óscar Fuentes wrote:
>> Stefan Kangas <stefan@marxist.se> writes:
>>
>>> The way I suggest we carry this out is an experiment on master for 30
>>> days, similarly to how we recently did with unbinding `M-o'.  This would
>>> allow us to gather feedback and see how well this works in practice.
>>
>> FWIW, I just tried both 0.15 and 0.10 and IMO it improves readability.

Thanks for testing.

>> There are some negative consequences, though, like the "line" of
>> display-fill-column-indicator-mode losing any apparience of continuity.

Given how that mode is implemented, by setting
`display-fill-column-indicator' to ?\u2502, I don't see how it could be
improved without a complete redesign.  It doesn't look like this was
implemented with `line-spacing' in mind.

> I'm not sure if there's an easy way to ensure the fill line looks
> continuous in this case, but if that could be improved, it would help in
> a few other areas even if line-spacing weren't increased. For example,
> with `org-prettify-entities' set to t, subscripts add a bit to the line
> height, causing the fill line to appear discontinuous. Likewise, I
> believe overlines add a bit to the line height too.

Do you have a recipe to reproduce this?



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06  9:26         ` Augusto Stoffel
  2021-05-06 10:10           ` Eli Zaretskii
@ 2021-05-06 20:22           ` Stefan Kangas
  1 sibling, 0 replies; 44+ messages in thread
From: Stefan Kangas @ 2021-05-06 20:22 UTC (permalink / raw)
  To: Augusto Stoffel; +Cc: Jim Porter, emacs-devel

Augusto Stoffel <arstoffel@gmail.com> writes:

> I wrote mostly to point out that changing the line spacing breaks any
> fancy box-drawing.  I'm not claiming this is more important than the
> other considerations you made, by the way.

My thinking here is that:

- Any modes relying heavily on this should set a `line-spacing' text
  property on the affected lines, or even set the variable
  `line-spacing' to nil for the entire buffer.

- This won't help users trying to make ASCII art, and the like.
  Maybe a menu entry for `line-spacing' could help with that.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 17:53                           ` Eli Zaretskii
  2021-05-06 17:57                             ` Eli Zaretskii
@ 2021-05-06 20:24                             ` Daniele Nicolodi
  1 sibling, 0 replies; 44+ messages in thread
From: Daniele Nicolodi @ 2021-05-06 20:24 UTC (permalink / raw)
  To: emacs-devel

On 06/05/2021 19:53, Eli Zaretskii wrote:
>> From: Daniele Nicolodi <daniele@grinta.net>
>> Date: Thu, 6 May 2021 18:57:46 +0200
>>
>> I didn't look at the code, but I don't think this is true: on my Emacs,
>> lines containing only "." or containing only "l" have exactly the same
>> height, as I would expect.
> 
> You assume that the metrics of these two glyphs are different in
> monospaced fonts?
> 
>> Also, lines containing only a new line character (thus no printable
>> characters) still have the same height as lines with content, as
>> expected.
> 
> Newline leaves no glyphs on display, so their metrics cannot be
> calculated from the font.
> 
>> Are you sure Emacs does not consider the maximum ascent and descent of
>> each _font_ contained in a line and not of each _glyph_?
> 
> Why do you think there's a difference?

Sorry for using a sloppy terminology, I don't work with these concept
often. Fonts have a logical size and a ink size. See for example

https://docs.gtk.org/Pango/method.GlyphString.extents.html

I meant to say that Emacs may be looking at the logical size of the
glyphs, which, for a monospaced font is indeed supposed to be the same
for every glyph, not at the ink size.

This small Python script prints the ink ang logical ascent and descent
for the "Fira Code 14" font for each command line argument:

import sys
import gi
gi.require_version('Pango', '1.0')
from gi.repository import Pango
gi.require_version('PangoCairo', '1.0')
from gi.repository import PangoCairo

map = PangoCairo.font_map_get_default()
ctx = map.create_context()
font = ctx.load_font(Pango.FontDescription('Fira Code 14'))

def pixels(x):
    return (x + 512) >> 10

def ascent(rect):
    return pixels(-rect.y)

def descent(rect):
    return pixels(rect.y + rect.height)

def extents(text):
    item = Pango.itemize(ctx, text, 0, len(text),
                         Pango.AttrList(), None)
    glyphs = Pango.GlyphString()
    Pango.shape(text, -1, item[0].analysis, glyphs)
    return glyphs.extents(font)

for text in sys.argv[1:]:
    ink, logical = extents(text)
    print("     text:", repr(text))
    print("      ink:", ascent(ink), descent(ink))
    print("  logical:", ascent(logical), descent(logical))
    print()

Please note that this is my first time using the Pango API for something
like this, thus there may be better ways to do it.

Cheers,
Dan



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 20:21     ` Stefan Kangas
@ 2021-05-06 23:17       ` Jim Porter
  2021-05-07  6:03         ` Yuri Khan
  2021-05-07  4:05       ` Eli Zaretskii
  1 sibling, 1 reply; 44+ messages in thread
From: Jim Porter @ 2021-05-06 23:17 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: emacs-devel

On Thu, May 6, 2021 at 1:21 PM Stefan Kangas <stefankangas@gmail.com> wrote:
>
> Jim Porter <jporterbugs@gmail.com> writes:
>
> > On 5/4/2021 9:12 AM, Óscar Fuentes wrote:
> >> There are some negative consequences, though, like the "line" of
> >> display-fill-column-indicator-mode losing any apparience of continuity.
>
> Given how that mode is implemented, by setting
> `display-fill-column-indicator' to ?\u2502, I don't see how it could be
> improved without a complete redesign.  It doesn't look like this was
> implemented with `line-spacing' in mind.

Yeah, Emacs' reliance on using characters to draw lines would probably
lead me to set `line-spacing' back to 0 if this were changed. It would
be interesting if Emacs were able to handle these issues, e.g. by
adding some special handling when it sees box-drawing characters, but
that would probably be a lot of work.

> > I'm not sure if there's an easy way to ensure the fill line looks
> > continuous in this case, but if that could be improved, it would help in
> > a few other areas even if line-spacing weren't increased. For example,
> > with `org-prettify-entities' set to t, subscripts add a bit to the line
> > height, causing the fill line to appear discontinuous. Likewise, I
> > believe overlines add a bit to the line height too.
>
> Do you have a recipe to reproduce this?

Sure, here it is. This might depend on the font used, though:

  emacs -Q
  C-x C-f file.org RET
  x_subscript RET
  foo RET
  bar RET
  M-x display-fill-column-indicator-mode
  ;; The fill column line should be continuous for most fonts
  M-x org-toggle-pretty-entities
  ;; The fill column line should be discontinuous between lines 1 and 2

Even on fonts where the fill column indicator is always discontinuous
(e.g. Deja Vu Sans Mono for me), `M-x org-toggle-pretty-entities'
makes the gap larger.

- Jim



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 20:21     ` Stefan Kangas
@ 2021-05-07  4:03       ` Eli Zaretskii
  2021-05-07 18:43         ` Stefan Kangas
  0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-07  4:03 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: rms, emacs-devel

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 6 May 2021 15:21:27 -0500
> Cc: emacs-devel@gnu.org
> 
> > Adding it to the "Options" menu, perhaps?
> >
> > Maybe that could be a good idea whether or not we change anything else?
> 
> I'm looking into adding this to the options menu, but would we want to
> do this for the current buffer, globally, or both?
> 
> My current thinking is that a user might want both, but this would make
> the menu too messy.  So perhaps we can get away with only supporting a
> global setting from the menu.  That should be the most common use-case,
> and if a user needs even more customization they will have to do it
> "manually".

IMO, we should provide both local and global settings.  But if we
provide only one, it should be the local one, because a global one
makes much less sense: there are buffers I can think about where
line-spacing would be an annoyance.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 20:21     ` Stefan Kangas
  2021-05-06 23:17       ` Jim Porter
@ 2021-05-07  4:05       ` Eli Zaretskii
  1 sibling, 0 replies; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-07  4:05 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: jporterbugs, emacs-devel

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 6 May 2021 15:21:48 -0500
> 
> >> There are some negative consequences, though, like the "line" of
> >> display-fill-column-indicator-mode losing any apparience of continuity.
> 
> Given how that mode is implemented, by setting
> `display-fill-column-indicator' to ?\u2502, I don't see how it could be
> improved without a complete redesign.  It doesn't look like this was
> implemented with `line-spacing' in mind.

We could use an image there instead of a character.  That doesn't
require redesign.

But any ASCII art will have the same problem, so this consideration is
not limited to that single feature.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-06 23:17       ` Jim Porter
@ 2021-05-07  6:03         ` Yuri Khan
  0 siblings, 0 replies; 44+ messages in thread
From: Yuri Khan @ 2021-05-07  6:03 UTC (permalink / raw)
  To: Jim Porter; +Cc: Stefan Kangas, Emacs developers

On Fri, 7 May 2021 at 06:18, Jim Porter <jporterbugs@gmail.com> wrote:

> Yeah, Emacs' reliance on using characters to draw lines would probably
> lead me to set `line-spacing' back to 0 if this were changed. It would
> be interesting if Emacs were able to handle these issues, e.g. by
> adding some special handling when it sees box-drawing characters, but
> that would probably be a lot of work.

The Kitty terminal emulator has a configuration option for increasing
the line spacing. To mitigate the box drawing characters issue, it
implements rendering them in code. (This also helps when a font does
not have glyphs for box drawing characters.)

https://github.com/kovidgoyal/kitty/blob/master/kitty/fonts/box_drawing.py

The high-level architecture is:

* Kitty keeps a texture that caches glyphs of fonts being used.
* For most characters, that texture is populated by rendering them
with the appropriate font (chosen by the user in configuration or by
font fallback).
* For box drawing characters, there is a mapping from character code
to a list of rendering functions, and they are called to render into
the texture.

Of course, Kitty has it easier because it only has to deal with a
single font size, and I’m not sure if it does complex script shaping
correctly.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-07  4:03       ` Eli Zaretskii
@ 2021-05-07 18:43         ` Stefan Kangas
  2021-05-08  6:19           ` Eli Zaretskii
  0 siblings, 1 reply; 44+ messages in thread
From: Stefan Kangas @ 2021-05-07 18:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rms, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> IMO, we should provide both local and global settings.

So how about this menu structure:

Options -> Set Line Height -> In this buffer -> 100 %
                                             -> 110 %
                                             -> ...
                                             -> 160 %
                           -> Global setting -> 100 %
                                             -> 110 %
                                             -> ...
                                             -> 160 %



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-07 18:43         ` Stefan Kangas
@ 2021-05-08  6:19           ` Eli Zaretskii
  2021-05-08  7:51             ` Daniele Nicolodi
  0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-08  6:19 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: rms, emacs-devel

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 7 May 2021 13:43:56 -0500
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > IMO, we should provide both local and global settings.
> 
> So how about this menu structure:
> 
> Options -> Set Line Height -> In this buffer -> 100 %
>                                              -> 110 %
>                                              -> ...
>                                              -> 160 %
>                            -> Global setting -> 100 %
>                                              -> 110 %
>                                              -> ...
>                                              -> 160 %
 
First, "Line Height" sounds like incorrect name to me.  Both Emacs and
other editors out there call this "Line Spacing", so why not use just
that (without the "Set" part)?

And second, 7 predefined values sounds too much.  I think we should
have 3 predefined possibilities: 1, 1.5, and 2, and one more asking
the user to provide the value.

On the implementation side, I'm not sure I understand how do you
intend to implement these values: 110% of what?  Line spacing is
eventually a pixel value; you can, of course, compute it in percents
of the font size, but then the nominal spacing will not have the 100%
or 1.0 value, right?  So how do you intend to convert the value in the
menu into the actual line-spacing value?



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-08  6:19           ` Eli Zaretskii
@ 2021-05-08  7:51             ` Daniele Nicolodi
  2021-05-08  8:06               ` Eli Zaretskii
  0 siblings, 1 reply; 44+ messages in thread
From: Daniele Nicolodi @ 2021-05-08  7:51 UTC (permalink / raw)
  To: emacs-devel

On 08/05/2021 08:19, Eli Zaretskii wrote:
> On the implementation side, I'm not sure I understand how do you
> intend to implement these values: 110% of what?  Line spacing is
> eventually a pixel value; you can, of course, compute it in percents
> of the font size, but then the nominal spacing will not have the 100%
> or 1.0 value, right?  So how do you intend to convert the value in the
> menu into the actual line-spacing value?

The documentation for the line-spacing variable says:

Documentation:
Additional space to put between lines when displaying a buffer. The
space is measured in pixels, and put below lines on graphic displays,
see ‘display-graphic-p’.
If value is a floating point number, it specifies the spacing relative
to the default frame line height.  A value of nil means add no extra space.

I think the values in the menu would simply be divided by 100.

Cheers,
Dan





^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-08  7:51             ` Daniele Nicolodi
@ 2021-05-08  8:06               ` Eli Zaretskii
  2021-05-08  9:40                 ` Daniele Nicolodi
  0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2021-05-08  8:06 UTC (permalink / raw)
  To: Daniele Nicolodi; +Cc: emacs-devel

> From: Daniele Nicolodi <daniele@grinta.net>
> Date: Sat, 8 May 2021 09:51:12 +0200
> 
> On 08/05/2021 08:19, Eli Zaretskii wrote:
> > On the implementation side, I'm not sure I understand how do you
> > intend to implement these values: 110% of what?  Line spacing is
> > eventually a pixel value; you can, of course, compute it in percents
> > of the font size, but then the nominal spacing will not have the 100%
> > or 1.0 value, right?  So how do you intend to convert the value in the
> > menu into the actual line-spacing value?
> 
> The documentation for the line-spacing variable says:
> 
> Documentation:
> Additional space to put between lines when displaying a buffer. The
> space is measured in pixels, and put below lines on graphic displays,
> see ‘display-graphic-p’.
> If value is a floating point number, it specifies the spacing relative
> to the default frame line height.  A value of nil means add no extra space.
> 
> I think the values in the menu would simply be divided by 100.

So you are saying that 100% would mean line-spacing equal to the
default frame line height?  That would mean the line height that is
twice as high as the default, so (a) 100% is hardly a good
description, and (b) how do you provide an option to get back to the
default value?

IOW, the default is that we add zero spacing, and that makes percent
notation not trivially convertible.  As the doc string says, this is
_additional_ space.



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal]
  2021-05-08  8:06               ` Eli Zaretskii
@ 2021-05-08  9:40                 ` Daniele Nicolodi
  0 siblings, 0 replies; 44+ messages in thread
From: Daniele Nicolodi @ 2021-05-08  9:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

On 08/05/2021 10:06, Eli Zaretskii wrote:
>> From: Daniele Nicolodi <daniele@grinta.net>
>> Date: Sat, 8 May 2021 09:51:12 +0200
>>
>> On 08/05/2021 08:19, Eli Zaretskii wrote:
>>> On the implementation side, I'm not sure I understand how do you
>>> intend to implement these values: 110% of what?  Line spacing is
>>> eventually a pixel value; you can, of course, compute it in percents
>>> of the font size, but then the nominal spacing will not have the 100%
>>> or 1.0 value, right?  So how do you intend to convert the value in the
>>> menu into the actual line-spacing value?
>>
>> The documentation for the line-spacing variable says:
>>
>> Documentation:
>> Additional space to put between lines when displaying a buffer. The
>> space is measured in pixels, and put below lines on graphic displays,
>> see ‘display-graphic-p’.
>> If value is a floating point number, it specifies the spacing relative
>> to the default frame line height.  A value of nil means add no extra space.
>>
>> I think the values in the menu would simply be divided by 100.
> 
> So you are saying that 100% would mean line-spacing equal to the
> default frame line height?  That would mean the line height that is
> twice as high as the default, so (a) 100% is hardly a good
> description, and (b) how do you provide an option to get back to the
> default value?
> 
> IOW, the default is that we add zero spacing, and that makes percent
> notation not trivially convertible.  As the doc string says, this is
> _additional_ space.

I have no idea what the author of the patch had in mind, I wa trying to
offer an interpretation. But, indeed simply dividing by 100 does not
work. Dividinng by 100 and subtracting 1 results in a number in the
correct range. However, I agree that "line spacing 100%" is a very bad
description of what the setting does.

Either the setting is called line "line height" with suggested values an
a neighborhood of 100%, or "line spacing" with values in a neighborhood
of 0% (ie 0%, 5%, 10% or so).

Cheers,
Dan




^ permalink raw reply	[flat|nested] 44+ messages in thread

end of thread, other threads:[~2021-05-08  9:40 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-04 15:57 Increase default `line-spacing' to 0.05, 0.10 or 0.15 [proposal] Stefan Kangas
2021-05-04 16:12 ` Óscar Fuentes
2021-05-04 16:59   ` Jim Porter
2021-05-05  7:08     ` Augusto Stoffel
2021-05-05  8:51       ` Daniel Mendler
2021-05-05 19:47       ` Stefan Kangas
2021-05-06  9:26         ` Augusto Stoffel
2021-05-06 10:10           ` Eli Zaretskii
2021-05-06 11:47             ` Augusto Stoffel
2021-05-06 11:57               ` Eli Zaretskii
2021-05-06 12:27                 ` Augusto Stoffel
2021-05-06 15:21                   ` Eli Zaretskii
2021-05-06 15:46                     ` Augusto Stoffel
2021-05-06 16:16                       ` Eli Zaretskii
2021-05-06 12:30                 ` Gregory Heytings
2021-05-06 15:22                   ` Eli Zaretskii
2021-05-06 16:21                     ` Gregory Heytings
2021-05-06 16:29                       ` Eli Zaretskii
2021-05-06 16:57                         ` Daniele Nicolodi
2021-05-06 17:53                           ` Eli Zaretskii
2021-05-06 17:57                             ` Eli Zaretskii
2021-05-06 20:24                             ` Daniele Nicolodi
2021-05-06 17:01                         ` Gregory Heytings
2021-05-06 17:34                           ` Eli Zaretskii
2021-05-06 18:15                             ` Gregory Heytings
2021-05-06 20:22           ` Stefan Kangas
2021-05-06 20:21     ` Stefan Kangas
2021-05-06 23:17       ` Jim Porter
2021-05-07  6:03         ` Yuri Khan
2021-05-07  4:05       ` Eli Zaretskii
2021-05-04 16:18 ` Eli Zaretskii
2021-05-04 21:29   ` Stefan Kangas
2021-05-05  2:28     ` Eli Zaretskii
2021-05-05  5:14 ` Richard Stallman
2021-05-05 19:16   ` Stefan Kangas
2021-05-06 20:21     ` Stefan Kangas
2021-05-07  4:03       ` Eli Zaretskii
2021-05-07 18:43         ` Stefan Kangas
2021-05-08  6:19           ` Eli Zaretskii
2021-05-08  7:51             ` Daniele Nicolodi
2021-05-08  8:06               ` Eli Zaretskii
2021-05-08  9:40                 ` Daniele Nicolodi
2021-05-05 12:18 ` Daniele Nicolodi
2021-05-05 19:17   ` Stefan Kangas

unofficial mirror of emacs-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/emacs-devel/0 emacs-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 emacs-devel emacs-devel/ https://yhetil.org/emacs-devel \
		emacs-devel@gnu.org
	public-inbox-index emacs-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.devel
	nntp://news.gmane.io/gmane.emacs.devel


code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git