Proportional fonts in the mode line (one month test)

Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

I've now switched master over to defaulting to proportional fonts in the
mode line.  Customise the `mode-line' face to get the old look back.

I've made the most obvious things that change size -- the U:-- thing,
the top/bot, and the line/col thing -- use the `min-width' spec, so
things should jump around (for those that care about that).

There's probably more things that should be handled that way, but we'll
take that as we go along.

This is just a test: If everybody hates this default, we won't proceed,
but we won't know unless we test it.  So we're now testing this on the
trunk for a month.  Vote in a month.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> This is just a test: If everybody hates this default, we won't proceed,
> but we won't know unless we test it.  So we're now testing this on the
> trunk for a month.  Vote in a month.

(Oh, and let me know if there's any segfaults, display glitches, or
general performance regressions.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> (Oh, and let me know if there's any segfaults, display glitches, or
> general performance regressions.)

Hm, I thought I had really messed something up, because I went to
gmane.test and read a post there with emojis in the From header, and
Emacs segfaulted immediately.  🤐  But then I checked out an earlier
version of the trunk, and it still segfaulted, so it's apparently not
something I did now...

I'm investigating, though, and trying to bisect, but it takes a while on
this laptop.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

If anybody else is also trying to debug -- it's failing with:

xdisp.c:31539: Emacs fatal error: assertion failed: it->ascent >= 0 && it->descent >= 0


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 24 Nov 2021 15:16:20 +0100
> 
> If anybody else is also trying to debug -- it's failing with:
> 
> xdisp.c:31539: Emacs fatal error: assertion failed: it->ascent >= 0 && it->descent >= 0

Is there a test case which segfaults?

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> xdisp.c:31539: Emacs fatal error: assertion failed: it->ascent >= 0
>> && it->descent >= 0
>
> Is there a test case which segfaults?

Yes, loading the text here into master seems to crash it:

http://quimby.gnus.org/s/crash.txt

So don't do that in the Emacs you're using.  :-)

However, I'm seeing weird stuff when trying to bisect -- I'm doing some
"make bootstraps" now to confirm that it's just not my build that's
broken -- I tried the same on a different Debian machine, and it didn't
segfault there.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 24 Nov 2021 15:46:58 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> xdisp.c:31539: Emacs fatal error: assertion failed: it->ascent >= 0
> >> && it->descent >= 0
> >
> > Is there a test case which segfaults?
> 
> Yes, loading the text here into master seems to crash it:
> 
> http://quimby.gnus.org/s/crash.txt

It doesn't crash here, with the latest master.

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It doesn't crash here, with the latest master.

*phew*  Then I guess it's a combination of features or fonts,
 perhaps...  Hm...

Aha!  That build finally finished.  It only crashes with
--with-xwidgets!  So perhaps it's not related to these changes today at
all, but with some interaction beween fonts and xwidget changes from the
past couple of days?  (I think that's when I last restarted my main
Emacs.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Aha!  That build finally finished.  It only crashes with
> --with-xwidgets! 

No, of course that wasn't it.  It was --enable-checking.  D'oh.

So I'm now able to reproduce the problem on the faster build machine,
which should help.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> No, of course that wasn't it.  It was --enable-checking.  D'oh.
>
> So I'm now able to reproduce the problem on the faster build machine,
> which should help.  

I assumed that this problem had to be pretty recent, but I'm now back to 

58bdfd7c540c49f3727c517c3599c9d601696caf

(which is December 31sth 2020), and the abort is still there:

xdisp.c:31003: Emacs fatal error: assertion failed: it->ascent >= 0 && it->descent >= 0
Fatal error 6: Aborted
Backtrace:
./src/emacs(+0x19d4d1)[0x5628f66344d1]
./src/emacs(+0x50756)[0x5628f64e7756]
./src/emacs(+0x5653e)[0x5628f64ed53e]

So perhaps it's more productive to try to debug it than trying to chase
the problem down, but before I do that: Is anybody else seeing this?

The way to reproduce it is:

./configure --enable-checking
make
./src/emacs /tmp/crash.txt

where that file contains the contents of:

http://quimby.gnus.org/s/crash.txt

I'm reproducing this on Debian/bullseye and Debian/bookworm.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Robert Pluim]

>>>>> On Wed, 24 Nov 2021 18:01:27 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Lars Ingebrigtsen <larsi@gnus.org> writes:
    >> No, of course that wasn't it.  It was --enable-checking.  D'oh.
    >> 
    >> So I'm now able to reproduce the problem on the faster build machine,
    >> which should help.  

    Lars> I assumed that this problem had to be pretty recent, but I'm now back to 

    Lars> 58bdfd7c540c49f3727c517c3599c9d601696caf

    Lars> (which is December 31sth 2020), and the abort is still there:

    Lars> xdisp.c:31003: Emacs fatal error: assertion failed: it->ascent >= 0 && it->descent >= 0
    Lars> Fatal error 6: Aborted
    Lars> Backtrace:
    Lars> ./src/emacs(+0x19d4d1)[0x5628f66344d1]
    Lars> ./src/emacs(+0x50756)[0x5628f64e7756]
    Lars> ./src/emacs(+0x5653e)[0x5628f64ed53e]

    Lars> So perhaps it's more productive to try to debug it than trying to chase
    Lars> the problem down, but before I do that: Is anybody else seeing this?

    Lars> The way to reproduce it is:

    Lars> ./configure --enable-checking
    Lars> make
    Lars> ./src/emacs /tmp/crash.txt

    Lars> where that file contains the contents of:

    Lars> http://quimby.gnus.org/s/crash.txt

Iʼm not seeing it. Iʼm seeing some of those codepoints being displayed
using the 'x' backend, but I guess I could always install some more
fonts....

Robert
-- 

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Iʼm not seeing it. Iʼm seeing some of those codepoints being displayed
> using the 'x' backend, but I guess I could always install some more
> fonts....

Just displaying this character, for instance, reliably crashes:

code point in charset: 0xACE0
               script: hangul
               syntax: w 	which means: word
             category: .:Base, L:Strong L2R, h:Korean
             to input: type "C-x 8 RET ace0" or "C-x 8 RET HANGUL SYLLABLE GO"
          buffer code: #xEA #xB3 #xA0
            file code: #xEA #xB3 #xA0 (encoded by coding system utf-8-unix)
              display: by this font (glyph code):
    x:-daewoo-mincho-medium-r-normal--24-170-100-100-c-240-ksc5601.1987-0 (#x306D)

Character code properties: customize what to show
  name: HANGUL SYLLABLE GO
  general-category: Lo (Letter, Other)
  decomposition: (44256) ('고')

Or any other Hangul character, apparently.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Andreas Schwab]

On Nov 25 2021, Lars Ingebrigtsen wrote:

>   decomposition: (44256) ('고')

But that didn't crash it?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Nov 25 2021, Lars Ingebrigtsen wrote:
>
>>   decomposition: (44256) ('고')
>
> But that didn't crash it?

I'm not using --enable-checking in the Emacs I'm typing in currently.
(And I meant to remove that bit before posting, in case it crashes
somebody else, but I forgot to.  Sorry!)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Robert Pluim]

>>>>> On Thu, 25 Nov 2021 13:51:11 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> Iʼm not seeing it. Iʼm seeing some of those codepoints being displayed
    >> using the 'x' backend, but I guess I could always install some more
    >> fonts....

    Lars> Just displaying this character, for instance, reliably crashes:

    Lars> code point in charset: 0xACE0
    Lars>                script: hangul
    Lars>                syntax: w 	which means: word
    Lars>              category: .:Base, L:Strong L2R, h:Korean
    Lars>              to input: type "C-x 8 RET ace0" or "C-x 8 RET HANGUL SYLLABLE GO"
    Lars>           buffer code: #xEA #xB3 #xA0
    Lars>             file code: #xEA #xB3 #xA0 (encoded by coding system utf-8-unix)
    Lars>               display: by this font (glyph code):
    Lars>     x:-daewoo-mincho-medium-r-normal--24-170-100-100-c-240-ksc5601.1987-0 (#x306D)

    Lars> Character code properties: customize what to show
    Lars>   name: HANGUL SYLLABLE GO
    Lars>   general-category: Lo (Letter, Other)
    Lars>   decomposition: (44256) ('고')

    Lars> Or any other Hangul character, apparently.

Not for me, with exactly the same font. This is only with
'--enable-checking'? Iʼm on bullseye, but Iʼm a bit behind on my
updates...

Robert
-- 

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Not for me, with exactly the same font. This is only with
> '--enable-checking'? Iʼm on bullseye, but Iʼm a bit behind on my
> updates...

Yes, this is with just

./configure --enable-checking

on both Debian/bullseye and Debian/bookworm.

Since this is just me, I'm starting wonder whether I have some sort of
build artefact in my tree that even "make extraclean" isn't getting rid
of.  I'll try a totally fresh tree.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Since this is just me, I'm starting wonder whether I have some sort of
> build artefact in my tree that even "make extraclean" isn't getting rid
> of.  I'll try a totally fresh tree.

Same result -- it still aborts.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Gregory Heytings]

>> Since this is just me, I'm starting wonder whether I have some sort of 
>> build artefact in my tree that even "make extraclean" isn't getting rid 
>> of.  I'll try a totally fresh tree.
>
> Same result -- it still aborts.
>

I just tried it on my Debian bookworm computer, and it doesn't abort, with 
the exact same font.  Perhaps it's a bug in some specific version of some 
library?  Is your Debian computer up-to-date?

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> I just tried it on my Debian bookworm computer, and it doesn't abort,
> with the exact same font.  Perhaps it's a bug in some specific version
> of some library?  Is your Debian computer up-to-date?

I did an update/upgrade, re-configured Emacs and re-built, and it's
still aborting.  :-/

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Gregory Heytings]

>> I just tried it on my Debian bookworm computer, and it doesn't abort, 
>> with the exact same font.  Perhaps it's a bug in some specific version 
>> of some library?  Is your Debian computer up-to-date?
>
> I did an update/upgrade, re-configured Emacs and re-built, and it's 
> still aborting.  :-/
>

Does it abort with

git clean -xdf && ./autogen.sh && ./configure --enable-checking && make && 
./src/emacs -Q crash.txt

?

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> Does it abort with
>
> git clean -xdf && ./autogen.sh && ./configure --enable-checking &&
> make && ./src/emacs -Q crash.txt
>
> ?

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Gregory Heytings]

>> Does it abort with
>>
>> git clean -xdf && ./autogen.sh && ./configure --enable-checking && make 
>> && ./src/emacs -Q crash.txt
>>
>> ?
>
> Yup.
>

Is gcc --version "gcc (Debian 11.2.0-10) 11.2.0"?

Is CFLAGS='-g3 -O2'?

Is apt show libcairo2|grep ^Version "1.16.0-5"?

Is apt show libharfbuzz-bin|grep ^Version "2.7.4-1"?

Is apt show libfreetype6|grep ^Version "2.11.0+dfsg-1"?

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> Is gcc --version "gcc (Debian 11.2.0-10) 11.2.0"?
>
> Is CFLAGS='-g3 -O2'?
>
> Is apt show libcairo2|grep ^Version "1.16.0-5"?
>
> Is apt show libharfbuzz-bin|grep ^Version "2.7.4-1"?
>
> Is apt show libfreetype6|grep ^Version "2.11.0+dfsg-1"?

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 25 Nov 2021 15:51:23 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Since this is just me, I'm starting wonder whether I have some sort of
> > build artefact in my tree that even "make extraclean" isn't getting rid
> > of.  I'll try a totally fresh tree.
> 
> Same result -- it still aborts.

Please show a full backtrace, maybe it can provide some hints or
ideas.  Also, the values of the variables involved in this.

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Please show a full backtrace, maybe it can provide some hints or
> ideas.  Also, the values of the variables involved in this.

I haven't really tried to debug this at all -- I just wondered whether
I'm the only person in the universe that's seeing the issue, and it
seems like I am?

Here's the results from gdb with -O2:

#0  raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x00005555555a6e5e in terminate_due_to_signal
    (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647)
    at emacs.c:443
#2  0x00005555555acd6e in die
    (msg=msg@entry=0x555555825948 "it->ascent >= 0 && it->descent >= 0", file=file@entry=0x5555558230a8 "xdisp.c", line=line@entry=31556) at alloc.c:7491
#3  0x000055555559d065 in gui_produce_glyphs (it=<optimized out>)
    at xdisp.c:31556
#4  0x000055555560921b in display_line
    (it=0x7fffffff6110, cursor_vpos=<optimized out>) at xdisp.c:23998
#5  0x0000555555610b83 in try_window
    (window=0x55555618a755, pos=..., flags=<optimized out>) at xdisp.c:19811
#6  0x0000555555627a58 in redisplay_window
    (window=0x55555618a755, just_this_one_p=<optimized out>) at xdisp.c:19218
#7  0x000055555562bd1b in redisplay_window_0
    (window=window@entry=0x55555618a755) at xdisp.c:16929
#8  0x000055555576c4f4 in internal_condition_case_1
    (bfun=bfun@entry=0x55555562bcf0 <redisplay_window_0>, arg=arg@entry=0x55555618a755, handlers=<optimized out>, hfun=hfun@entry=0x5555555db5c0 <redisplay_window_error>) at eval.c:1519
#9  0x00005555555dbb11 in redisplay_windows (window=0x55555618a755)
    at xdisp.c:16909
#10 0x0000555555614a3d in redisplay_internal () at xdisp.c:16377
#11 0x00005555556e66be in read_char
    (commandflag=1, map=0x5555565bc1c3, prev_event=0x0, used_mouse_menu=0x7fffffffdbbb, end_time=0x0) at keyboard.c:2556
#12 0x00005555556e9285 in read_key_sequence
    (keybuf=<optimized out>, prompt=0x0, dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>) at keyboard.c:9616
#13 0x00005555556eae84 in command_loop_1 () at keyboard.c:1393
#14 0x000055555576c447 in internal_condition_case
    (bfun=bfun@entry=0x5555556eac50 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x5555556e00c0 <cmd_error>) at eval.c:1495
#15 0x00005555556d87d6 in command_loop_2 (handlers=handlers@entry=0x90)
    at keyboard.c:1134
#16 0x000055555576c381 in internal_catch
    (tag=<optimized out>, func=func@entry=0x5555556d87b0 <command_loop_2>, arg=arg@entry=0x90) at eval.c:1226
#17 0x00005555556d93ac in command_loop () at keyboard.c:1112
#18 0x00005555556dfbea in recursive_edit_1 () at keyboard.c:721
#19 0x00005555556dff8c in Frecursive_edit () at keyboard.c:804
#20 0x00005555555be712 in main (argc=3, argv=<optimized out>) at emacs.c:2409

With -O0:

#0  raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x0000555555734c64 in terminate_due_to_signal
    (sig=6, backtrace_limit=2147483647) at emacs.c:443
#2  0x00005555557e6aa0 in die
    (msg=0x555555926f08 "it->ascent >= 0 && it->descent >= 0", file=0x555555920f4f "xdisp.c", line=31556) at alloc.c:7491
#3  0x000055555563223c in gui_produce_glyphs (it=0x7fffffff85e0)
    at xdisp.c:31556
#4  0x0000555555616325 in display_line (it=0x7fffffff85e0, cursor_vpos=0)
    at xdisp.c:23998
#5  0x0000555555607e0b in try_window (window=0x55555627ea35, pos=..., flags=1)
    at xdisp.c:19811
#6  0x00005555556049eb in redisplay_window
    (window=0x55555627ea35, just_this_one_p=false) at xdisp.c:19218
#7  0x00005555555fc48e in redisplay_window_0 (window=0x55555627ea35)
    at xdisp.c:16929
#8  0x000055555581d35c in internal_condition_case_1
    (bfun=0x5555555fc44c <redisplay_window_0>, arg=0x55555627ea35, handlers=0x7ffff1e9431b, hfun=0x5555555fc414 <redisplay_window_error>) at eval.c:1519
#9  0x00005555555fc3ea in redisplay_windows (window=0x55555627ea35)
    at xdisp.c:16909
#10 0x00005555555fadd8 in redisplay_internal () at xdisp.c:16377
#11 0x00005555555f88f5 in redisplay () at xdisp.c:15587
#12 0x0000555555740e5c in read_char
    (commandflag=1, map=0x555556710f53, prev_event=0x0, used_mouse_menu=0x7fffffffda5f, end_time=0x0) at keyboard.c:2556
#13 0x00005555557546e0 in read_key_sequence
    (keybuf=0x7fffffffdc60, prompt=0x0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
    at keyboard.c:9616
#14 0x000055555573d3a8 in command_loop_1 () at keyboard.c:1393
#15 0x000055555581d27b in internal_condition_case
    (bfun=0x55555573cf26 <command_loop_1>, handlers=0x90, hfun=0x55555573c342 <cmd_error>) at eval.c:1495
#16 0x000055555573cae6 in command_loop_2 (handlers=0x90) at keyboard.c:1134
#17 0x000055555581c484 in internal_catch
    (tag=0xe9d0, func=0x55555573cabc <command_loop_2>, arg=0x90) at eval.c:1226
#18 0x000055555573ca88 in command_loop () at keyboard.c:1112
#19 0x000055555573bdee in recursive_edit_1 () at keyboard.c:721
#20 0x000055555573c010 in Frecursive_edit () at keyboard.c:804
#21 0x0000555555737cc8 in main (argc=3, argv=0x7fffffffe148) at emacs.c:2409


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 13:18:58 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please show a full backtrace, maybe it can provide some hints or
> > ideas.  Also, the values of the variables involved in this.
> 
> I haven't really tried to debug this at all -- I just wondered whether
> I'm the only person in the universe that's seeing the issue, and it
> seems like I am?
> 
> Here's the results from gdb with -O2:
> 
> #0  raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
> #1  0x00005555555a6e5e in terminate_due_to_signal
>     (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647)
>     at emacs.c:443
> #2  0x00005555555acd6e in die
>     (msg=msg@entry=0x555555825948 "it->ascent >= 0 && it->descent >= 0", file=file@entry=0x5555558230a8 "xdisp.c", line=line@entry=31556) at alloc.c:7491
> #3  0x000055555559d065 in gui_produce_glyphs (it=<optimized out>)
>     at xdisp.c:31556

What does the following show?

 (gdb) fr 3
 (gdb) source /path/to/emacs/src/.gdbinit
 (gdb) p it->what
 (gdb) p/x it->c
 (gdb) pgrowx it->glyph_row

The last command should display the entire glyph row you have there,
which maybe will tell us something useful.  The two commands before it
could also be useful.

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> What does the following show?
>
>  (gdb) fr 3
>  (gdb) source /path/to/emacs/src/.gdbinit
>  (gdb) p it->what
>  (gdb) p/x it->c
>  (gdb) pgrowx it->glyph_row
>
> The last command should display the entire glyph row you have there,
> which maybe will tell us something useful.  The two commands before it
> could also be useful.

Let's see...

(gdb) fr 3
#3  0x000055555563223c in gui_produce_glyphs (it=0x7fffffff85e0)
    at xdisp.c:31557
31557	  eassert (it->ascent >= 0 && it->descent >= 0);
(gdb) source src/.gdbinit 
Warning: /home/larsi/src/emacs/test/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :1
TERM = xterm-256color
Breakpoint 1 at 0x555555734b7e: file emacs.c, line 406.
Breakpoint 2 at 0x5555556f579e: file xterm.c, line 11627.
(gdb) p it->what
$1 = IT_CHARACTER
(gdb) p/x it->c
$2 = 0xace0
(gdb) pgrowx it->glyph_row
TEXT: 2 glyphs
  0    0: CHAR[^] pos=1 blev=0,btyp=L w=22 a+d=35+9 MB
  1   22: CHAR[0xace0] pos=2 blev=0,btyp=L w=24 a+d=25+-1 face=21 MB


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 15:30:45 +0100
> 
> (gdb) p it->what
> $1 = IT_CHARACTER
> (gdb) p/x it->c
> $2 = 0xace0
> (gdb) pgrowx it->glyph_row
> TEXT: 2 glyphs
>   0    0: CHAR[^] pos=1 blev=0,btyp=L w=22 a+d=35+9 MB
>   1   22: CHAR[0xace0] pos=2 blev=0,btyp=L w=24 a+d=25+-1 face=21 MB

OK, so the glyph for this character, U+ACE0, comes out with a negative
descent value of -1.

Please run Emacs again, under GDB, with a breakpoint like this:

  (gdb) break xdisp.c:30866 if it->c == 0xace0

The breakpoint should be on the line shown with "<<<<" below:

  void
  gui_produce_glyphs (struct it *it)
  {
    int extra_line_spacing = it->extra_line_spacing;

    it->glyph_not_available_p = false;

    if (it->what == IT_CHARACTER)
      {
	unsigned char2b;
	struct face *face = FACE_FROM_ID (it->f, it->face_id);
	struct font *font = face->font;
	struct font_metrics *pcm = NULL;
	int boff;			/* Baseline offset.  */

	if (font == NULL)  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
	  {
	    /* When no suitable font is found, display this character by
	       the method specified in the first extra slot of
	       Vglyphless_char_display.  */
		Lisp_Object acronym = lookup_glyphless_char_display (-1, it);

Then step with the "next" command through the code there, and see
where it->descent gets its negative value.  In particular, when you
get to this part:

	  if (get_char_glyph_code (it->char_to_display, font, &char2b))
	    {
	      pcm = get_per_char_metric (font, &char2b);
	      if (pcm->width == 0
		  && pcm->rbearing == 0 && pcm->lbearing == 0)
		pcm = NULL;
	    }

	  if (pcm)
	    {
	      it->phys_ascent = pcm->ascent + boff;
	      it->phys_descent = pcm->descent - boff;
	      it->pixel_width = pcm->width;

please tell what are the values of pcm->ascent and pcm->descent.

I want to know whether the font is the culprit or some code of ours
overrides the value from the font.  Then we can devise the solution.

Thanks.

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> 	  if (pcm)
> 	    {
> 	      it->phys_ascent = pcm->ascent + boff;
> 	      it->phys_descent = pcm->descent - boff;
> 	      it->pixel_width = pcm->width;
>
> please tell what are the values of pcm->ascent and pcm->descent.
>
> I want to know whether the font is the culprit or some code of ours
> overrides the value from the font.  Then we can devise the solution.

gdb) next
30909		      it->phys_ascent = pcm->ascent + boff;
(gdb) p pcm->ascent 
$1 = 18
(gdb) p pcm->descent 
$2 = -3


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 16:04:57 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 	  if (pcm)
> > 	    {
> > 	      it->phys_ascent = pcm->ascent + boff;
> > 	      it->phys_descent = pcm->descent - boff;
> > 	      it->pixel_width = pcm->width;
> >
> > please tell what are the values of pcm->ascent and pcm->descent.
> >
> > I want to know whether the font is the culprit or some code of ours
> > overrides the value from the font.  Then we can devise the solution.
> 
> gdb) next
> 30909		      it->phys_ascent = pcm->ascent + boff;
> (gdb) p pcm->ascent 
> $1 = 18
> (gdb) p pcm->descent 
> $2 = -3

So the glyph metrics also report a negative descent.

But what about the font?  We don't use the above for it->descent, at
least not directly.  So where in the code did it->descent get
negative?

Re: Crash with --enable-checking and some glyphs

[Eli Zaretskii]

Ping!  Can you please show the information I asked for?  I'd like to
find a solution to this problem.

> Date: Fri, 26 Nov 2021 18:27:59 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> > Date: Fri, 26 Nov 2021 16:04:57 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > 	  if (pcm)
> > > 	    {
> > > 	      it->phys_ascent = pcm->ascent + boff;
> > > 	      it->phys_descent = pcm->descent - boff;
> > > 	      it->pixel_width = pcm->width;
> > >
> > > please tell what are the values of pcm->ascent and pcm->descent.
> > >
> > > I want to know whether the font is the culprit or some code of ours
> > > overrides the value from the font.  Then we can devise the solution.
> > 
> > gdb) next
> > 30909		      it->phys_ascent = pcm->ascent + boff;
> > (gdb) p pcm->ascent 
> > $1 = 18
> > (gdb) p pcm->descent 
> > $2 = -3
> 
> So the glyph metrics also report a negative descent.
> 
> But what about the font?  We don't use the above for it->descent, at
> least not directly.  So where in the code did it->descent get
> negative?

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> But what about the font?  We don't use the above for it->descent, at
> least not directly.  So where in the code did it->descent get
> negative?

(gdb) p font->descent
$14 = 2
(gdb) print boff
$15 = 3

I think it has to be from here:

      if (it->char_to_display != '\n' && it->char_to_display != '\t')
	{
	  it->nglyphs = 1;

 	  if (it->override_ascent >= 0)
 	    {
 	      it->ascent = it->override_ascent;
 	      it->descent = it->override_descent;
 	      boff = it->override_boff;
 	    }
 	  else
 	    {
 	      it->ascent = FONT_BASE (font) + boff;
 	      it->descent = FONT_DESCENT (font) - boff;
 	    }

And boff is 3 because of:

      boff = font->baseline_offset;
      if (font->vertical_centering)
	boff = VCENTER_BASELINE_OFFSET (font, it->f) - boff;

(gdb) print font->vertical_centering 
$17 = true


And we don't apply these sanity checks in this case:

		      /* These limitations are enforced by an
			 assertion near the end of this function.  */
		      if (it->ascent < 0)
			it->ascent = 0;
		      if (it->descent < 0)
			it->descent = 0;


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 15:04:56 +0100
> 
>       if (it->char_to_display != '\n' && it->char_to_display != '\t')
> 	{
> 	  it->nglyphs = 1;
> 
>  	  if (it->override_ascent >= 0)
>  	    {
>  	      it->ascent = it->override_ascent;
>  	      it->descent = it->override_descent;
>  	      boff = it->override_boff;
>  	    }
>  	  else
>  	    {
>  	      it->ascent = FONT_BASE (font) + boff;
>  	      it->descent = FONT_DESCENT (font) - boff;
>  	    }
> 
> And boff is 3 because of:
> 
>       boff = font->baseline_offset;
>       if (font->vertical_centering)
> 	boff = VCENTER_BASELINE_OFFSET (font, it->f) - boff;
> 
> (gdb) print font->vertical_centering 
> $17 = true
> 
> 
> And we don't apply these sanity checks in this case:
> 
> 		      /* These limitations are enforced by an
> 			 assertion near the end of this function.  */
> 		      if (it->ascent < 0)
> 			it->ascent = 0;
> 		      if (it->descent < 0)
> 			it->descent = 0;

Right, I added a similar limitation, because I don't see what else
could we do in cases such as this one.  I do wonder why others didn't
see the same problem in a very similar build on the same system.

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Right, I added a similar limitation, because I don't see what else
> could we do in cases such as this one.

Thanks; that fixed the abort here.

> I do wonder why others didn't see the same problem in a very similar
> build on the same system.

Me too.  Po Lu did see a crash with the test file on Solaris, though, so
I wonder whether this fix also fixed that problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Me too.  Po Lu did see a crash with the test file on Solaris, though, so
> I wonder whether this fix also fixed that problem.

That was probably a bug with Developer Studio, since compiling with GCC
made it work.  I will see if it's still the case later today.

Re: Crash with --enable-checking and some glyphs

[Gregory Heytings]

Lars, could you check that md5sum 
/usr/share/fonts/X11/misc/hanglm24.pcf.gz = 
819a5304502ef38ac01918a147310b69 ?

>> And boff is 3 because of:
>>
>> boff = font->baseline_offset;
>> if (font->vertical_centering)
>>   boff = VCENTER_BASELINE_OFFSET (font, it->f) - boff;
>>
>> (gdb) print font->vertical_centering
>> $17 = true
>>
>> And we don't apply these sanity checks in this case:
>>
>> /* These limitations are enforced by an
>>    assertion near the end of this function.  */
>> if (it->ascent < 0)
>>   it->ascent = 0;
>> if (it->descent < 0)
>>   it->descent = 0;
>
> Right, I added a similar limitation, because I don't see what else could 
> we do in cases such as this one.  I do wonder why others didn't see the 
> same problem in a very similar build on the same system.
>

I very much doubt that this is the root cause of this bug.  I have the 
exact same libraries and compiler (and likely the same font), I use the 
exact same build options, and boff is never == 3 with that file, it is 
always == 0.

For the piece of code above, with the ACE0 character I have:

boff = font->baseline_offset; /* font->baseline_offset == 0 */
if (font->vertical_centering) /* font->vertical_centering == 1 */
   boff = VCENTER_BASELINE_OFFSET (font, it->f) - boff; /* VCENTER_BASELINE_OFFSET(...) == 0 */

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> Lars, could you check that md5sum
> /usr/share/fonts/X11/misc/hanglm24.pcf.gz =
> 819a5304502ef38ac01918a147310b69 ?

larsi@xo:~/src/emacs/trunk$ md5sum /usr/share/fonts/X11/misc/hanglm24.pcf.gz
819a5304502ef38ac01918a147310b69  /usr/share/fonts/X11/misc/hanglm24.pcf.gz

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Gregory Heytings]

>
> larsi@xo:~/src/emacs/trunk$ md5sum 
> /usr/share/fonts/X11/misc/hanglm24.pcf.gz 
> 819a5304502ef38ac01918a147310b69 
> /usr/share/fonts/X11/misc/hanglm24.pcf.gz
>

Thanks.  So I can update my previous post:

I very much doubt that this is the root cause of this bug.  We have the 
exact same libraries, same compiler and same font, we use the exact same 
build options, and boff is never == 3 with that file, it is always == 0.

For the piece of code above, with the ACE0 character I have:

boff = font->baseline_offset; /* font->baseline_offset == 0 */
if (font->vertical_centering) /* font->vertical_centering == 1 */
   boff = VCENTER_BASELINE_OFFSET (font, it->f) - boff; /* VCENTER_BASELINE_OFFSET(...) == 0 */

What do you have in font->baseline_offset?  And what does 
VCENTER_BASELINE_OFFSET return?

Re: Crash with --enable-checking and some glyphs

[Eli Zaretskii]

> Date: Sat, 27 Nov 2021 22:01:05 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, rpluim@gmail.com, emacs-devel@gnu.org
> 
> I very much doubt that this is the root cause of this bug.

What do you mean by "this"?

The fix that I installed didn't pretend to fix any root causes,
because those are not known.  I just verified that the code in that
part does its job and works according to what the font metrics
returned by the font backend feeds it.  Since the fonts are identical,
the root cause could be in the font backend (which is not our code) or
maybe elsewhere.  You are welcome to investigate further, but my
suggestion is to start from xftfont.c and its ilk, tracing the
information it returns for the font in question.

The problem is also extremely rare, because otherwise everyone who
builds Emacs with --enable-checking would see frequent crashes long
ago.

In any case, the installed fix just does what other branches of that
function already did for glyphs that are not simple character glyphs,
that's all.  It "corrects" the ascent and descent values after they
have been already used for the glyph metrics on our display, so its
effect on the display should be minimal at best, and usually nil.  But
if you have evidence to the contrary, by all means present it, and
let's see what we should and can do about that.

Re: Crash with --enable-checking and some glyphs

[Gregory Heytings]

>> I very much doubt that this is the root cause of this bug.
>
> What do you mean by "this"?
>

"This" means the absence of the "if (it->ascent < 0) it->ascent = 0;" and 
" if (it->descent < 0) it->descent = 0;" in that branch of the function. 
Indeed adding such limitations fixes the problem, but there is apparently 
another bug elsewhere that remains unfixed, and that could pop up later in 
a different form.

>
> Since the fonts are identical, the root cause could be in the font 
> backend (which is not our code) or maybe elsewhere.
>

The fonts are identical indeed, but the font backends are also identical. 
So the problem is likely not in the font backends.

>
> You are welcome to investigate further
>

I'll do that (if Lars agrees to answer my queries, because ATM I cannot 
reproduce the problem locally).

Re: Crash with --enable-checking and some glyphs

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

>> You are welcome to investigate further
>
> I'll do that (if Lars agrees to answer my queries, because ATM I
> cannot reproduce the problem locally).

I can't give priority to a problem that's now gone, and that I was the
only person who experienced, so I'm bowing out of this one.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Crash with --enable-checking and some glyphs

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> No, of course that wasn't it.  It was --enable-checking.  D'oh.
>>
>> So I'm now able to reproduce the problem on the faster build machine,
>> which should help.  
>
> I assumed that this problem had to be pretty recent, but I'm now back to 
>
> 58bdfd7c540c49f3727c517c3599c9d601696caf
>
> (which is December 31sth 2020), and the abort is still there:
>
> xdisp.c:31003: Emacs fatal error: assertion failed: it->ascent >= 0 && it->descent >= 0
> Fatal error 6: Aborted
> Backtrace:
> ./src/emacs(+0x19d4d1)[0x5628f66344d1]
> ./src/emacs(+0x50756)[0x5628f64e7756]
> ./src/emacs(+0x5653e)[0x5628f64ed53e]
>
> So perhaps it's more productive to try to debug it than trying to chase
> the problem down, but before I do that: Is anybody else seeing this?
>
> The way to reproduce it is:
>
> ./configure --enable-checking
> make
> ./src/emacs /tmp/crash.txt
>
> where that file contains the contents of:
>
> http://quimby.gnus.org/s/crash.txt
>
> I'm reproducing this on Debian/bullseye and Debian/bookworm.

Just tried with master (updated yesterday) on Debian Testing, configured
with

../emacs/configure --enable-checking
--without-toolkit-scroll-bars --with-x-toolkit=lucid --with-modules
--without-imagemagick

No crash.

Configured for 'x86_64-pc-linux-gnu'.

  Where should the build process find the source code?    ../emacs
  What compiler should emacs be built with?               gcc -g3 -O2
  Should Emacs use the GNU version of malloc?             no
    (The GNU allocators don't work with this system configuration.)
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          LUCID
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 yes
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes -lgif
  Does Emacs use a png library?                           yes -lpng16 -lz
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use -lwebp?                                  no
  Does Emacs use cairo?                                   yes
  Does Emacs use -llcms2?                                 no
  Does Emacs use imagemagick?                             no
  Does Emacs use native APIs for images?                  no
  Does Emacs support sound?                               yes
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  yes
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               yes
  Does Emacs use a file notification library?             yes -lglibc (inotify)
  Does Emacs use access control lists?                    no
  Does Emacs use -lselinux?                               yes
  Does Emacs use -lgnutls?                                yes
  Does Emacs use -lxml2?                                  yes
  Does Emacs use -lfreetype?                              yes
  Does Emacs use HarfBuzz?                                yes
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   yes
  Does Emacs use -lxft?                                   no
  Does Emacs use -lsystemd?                               no
  Does Emacs use -ljansson?                               yes
  Does Emacs use the GMP library?                         yes
  Does Emacs directly use zlib?                           yes
  Does Emacs have dynamic modules support?                yes
  Does Emacs use toolkit scroll bars?                     no
  Does Emacs support Xwidgets?                            no
  Does Emacs have threading support in lisp?              yes
  Does Emacs support the portable dumper?                 yes
  Does Emacs support legacy unexec dumping?               no
  Which dumping strategy does Emacs use?                  pdumper
  Does Emacs have native lisp compiler?                   yes
  Does Emacs use version 2 of the the X Input Extension?  no

Re: Crash with --enable-checking and some glyphs

[Gregor Zattler]

Hi Lars, emacs-devel,
* Lars Ingebrigtsen <larsi@gnus.org> [2021-11-24; 18:01]:
> The way to reproduce it is:
>
> ./configure --enable-checking
> make
> ./src/emacs /tmp/crash.txt
>
> where that file contains the contents of:
>
> http://quimby.gnus.org/s/crash.txt
>
> I'm reproducing this on Debian/bullseye and Debian/bookworm.


FWIW: That file dosn't crash my emacs, built on Debian/Buster:

In GNU Emacs 29.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0)
 of 2021-11-21 built on no
Repository revision: 74386abc0ff14affe2a9564c681d9e53cfe418e2
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)

Configured using:
 'configure -C --prefix=/usr/local/stow/emacs-snapshot
 --prefix=/usr/local/stow/emacs-snapshot
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/28.0/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/28.0/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=yes --without-gconf --with-mailutils --build
 x86_64-linux-gnu
 --infodir=/usr/local/share/info:/usr/share/info --with-json
 --with-file-notification=yes --with-cairo --with-x=yes
 --with-x-toolkit=lucid --without-toolkit-scroll-bars
 --enable-checking=yes --enable-check-lisp-object-type
 --with-native-compilation'




Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

Re: Crash with --enable-checking and some glyphs

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> ./src/emacs /tmp/crash.txt
>
> where that file contains the contents of:
>
> http://quimby.gnus.org/s/crash.txt

This crashes Emacs 28 with an illegal instruction error on a build with
no checking built with Cairo on Solaris 11.4.  Probably the latest SRU
and whatever version of Cairo it comes with.  I will try to get a
backtrace and report a bug the next time I have access to that machine.

Both GCC and Developer Studio produce builds that crash.

I can't get it to crash on any other system though, both with and
without checking.

Thanks.

Re: Crash with --enable-checking and some glyphs

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Both GCC and Developer Studio produce builds that crash.

False alarm, sorry for the noise.  Building with GCC results in a build
that doesn't crash.

Re: Proportional fonts in the mode line (one month test)

[Uwe Brauer]

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

>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> Aha!  That build finally finished.  It only crashes with
>> --with-xwidgets! 

> No, of course that wasn't it.  It was --enable-checking.  D'oh.

> So I'm now able to reproduce the problem on the faster build machine,
> which should help.  

So what is the state of art. Do you advice to give it a try or shall we
wait for you to fix that?

I usually just run 
./configure --prefix=/opt/emacs29 --with-x-toolkit=athena --without-pop --with-mailutils

And then 
make bootstrap

regards

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Uwe Brauer <oub@mat.ucm.es> writes:

> So what is the state of art. Do you advice to give it a try or shall we
> wait for you to fix that?

There's only a problem if you build with --enable-checking (unusual) and
read kanji.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 24 Nov 2021 20:12:36 +0100
> 
> Uwe Brauer <oub@mat.ucm.es> writes:
> 
> > So what is the state of art. Do you advice to give it a try or shall we
> > wait for you to fix that?
> 
> There's only a problem if you build with --enable-checking (unusual) and
> read kanji.

And evidently build with xwidget support (my Emacs is built with
--enable-checking).

Re: Proportional fonts in the mode line (one month test)

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> And evidently build with xwidget support (my Emacs is built with
> --enable-checking).

I tried browsing to `gmane.test' with master, but didn't see anything,
and Emoji displayed normally.  The build I used to test has
--enable-checking='yes,glyphs' and xwidgets enabled.

Lars, do you have a better reproducer?  Thanks.

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> I tried browsing to `gmane.test' with master, but didn't see anything,
> and Emoji displayed normally.  The build I used to test has
> --enable-checking='yes,glyphs' and xwidgets enabled.
>
> Lars, do you have a better reproducer?  Thanks.

Downloading this and putting it into a buffer crashes Emacs reliably for
me:

http://quimby.gnus.org/s/crash.txt

with ./configure --enable-checking and emacs -Q.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> There's only a problem if you build with --enable-checking (unusual) and
>> read kanji.
>
> And evidently build with xwidget support (my Emacs is built with
> --enable-checking).

No, I'm able to reproduce the problem with just --enable-checking --
xwidget was a red herring.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Aha!  That build finally finished.  It only crashes with
> --with-xwidgets!  So perhaps it's not related to these changes today at
> all, but with some interaction beween fonts and xwidget changes from the
> past couple of days?  (I think that's when I last restarted my main
> Emacs.)

Please send a reproducer (preferably as a file attachment or in this
message) that I can display, and I will debug this ASAP.  Thanks.

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 24 Nov 2021 14:53:03 +0100
> 
> This is just a test: If everybody hates this default, we won't proceed,
> but we won't know unless we test it.  So we're now testing this on the
> trunk for a month.  Vote in a month.

I hate it already, and promptly switched back.

Re: Proportional fonts in the mode line (one month test)

[Manuel Uberti]

On 24/11/21 15:40, Eli Zaretskii wrote:
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Wed, 24 Nov 2021 14:53:03 +0100
>>
>> This is just a test: If everybody hates this default, we won't proceed,
>> but we won't know unless we test it.  So we're now testing this on the
>> trunk for a month.  Vote in a month.

FWIW, I am willing to give it a try.

I already did try something along those lines when I had set 
modus-themes-variable-pitch-ui to t some months ago, but also I went back to my 
default monospace font after a while.

-- 
Manuel Uberti
www.manueluberti.eu

Re: Proportional fonts in the mode line (one month test)

[Yuri D'Elia]

On Wed, Nov 24 2021, Lars Ingebrigtsen wrote:
> I've now switched master over to defaulting to proportional fonts in the
> mode line.  Customise the `mode-line' face to get the old look back.

The hardest part of playing with the various faces for me is finding
groups that go well together.

For example, I really like the idea of having default and fixed-pitch
being two different stylistic choices. However, good luck finding two
distinct faces that have the same (absolutely identical) metrics.

There are only very few fonts where this can work well. Iosevka is one,
for example. Although the difference in stylistic sets are quite subtle,
so the distinction is not that strong either.

Having the minibuffer change in height because fixed-pitch occasionally
displays some additional hints is quite jarring, and the main reason
every time I try to customize default/fixed-pitch I end up setting them
to the same value.

I don't mind an individual line changing width so much by contrast. Also
the mode-line doesn't really have anything that I need to be aligned.

I'm giving this a shot.

Re: Proportional fonts in the mode line (one month test)

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now switched master over to defaulting to proportional fonts in the
> mode line.  Customise the `mode-line' face to get the old look back.
>
> I've made the most obvious things that change size -- the U:-- thing,
> the top/bot, and the line/col thing -- use the `min-width' spec, so
> things should jump around (for those that care about that).
>
> There's probably more things that should be handled that way, but we'll
> take that as we go along.
>
> This is just a test: If everybody hates this default, we won't proceed,
> but we won't know unless we test it.  So we're now testing this on the
> trunk for a month.  Vote in a month.

So far I like it.

However, as soon as some theme is activated, the modeline goes back to
monospace. How can I prevent that?

To reproduce:

emacs -Q
M-x load-theme modus-operandi

Re: Proportional fonts in the mode line (one month test)

[Yuan Fu]

> On Nov 24, 2021, at 8:38 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
>> I've now switched master over to defaulting to proportional fonts in the
>> mode line.  Customise the `mode-line' face to get the old look back.
>> 
>> I've made the most obvious things that change size -- the U:-- thing,
>> the top/bot, and the line/col thing -- use the `min-width' spec, so
>> things should jump around (for those that care about that).
>> 
>> There's probably more things that should be handled that way, but we'll
>> take that as we go along.
>> 
>> This is just a test: If everybody hates this default, we won't proceed,
>> but we won't know unless we test it.  So we're now testing this on the
>> trunk for a month.  Vote in a month.
> 
> So far I like it.
> 
> However, as soon as some theme is activated, the modeline goes back to
> monospace. How can I prevent that?
> 
> To reproduce:
> 
> emacs -Q
> M-x load-theme modus-operandi

I guess the theme set their own face for mode-line which inherited from default which uses a fixed-width font.

Yuan

Re: Proportional fonts in the mode line (one month test)

[Óscar Fuentes]

Yuan Fu <casouri@gmail.com> writes:

>> So far I like it.
>> 
>> However, as soon as some theme is activated, the modeline goes back to
>> monospace. How can I prevent that?
>> 
>> To reproduce:
>> 
>> emacs -Q
>> M-x load-theme modus-operandi
>
> I guess the theme set their own face for mode-line which inherited
> from default which uses a fixed-width font.

If this is true it is a common practice, because all themes I tried so
far (about 5) show this behavior.

I inspected nord-theme (1) and it contains

`(mode-line ((,class (:foreground ,nord8 :background ,nord3))))
`(mode-line-buffer-id ((,class (:weight bold))))
`(mode-line-highlight ((,class (:inherit highlight))))
`(mode-line-inactive ((,class (:foreground ,nord4 :background ,nord-uniform-mode-lines-background))))

1: https://github.com/arcticicestudio/nord-emacs

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> If this is true it is a common practice, because all themes I tried so
> far (about 5) show this behavior.
>
> I inspected nord-theme (1) and it contains
>
> `(mode-line ((,class (:foreground ,nord8 :background ,nord3))))
> `(mode-line-buffer-id ((,class (:weight bold))))
> `(mode-line-highlight ((,class (:inherit highlight))))
> `(mode-line-inactive ((,class (:foreground ,nord4 :background
> ,nord-uniform-mode-lines-background))))

Huh.  Odd that they don't inherit from `mode-line' and then override the
things they don't like, isn't it?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Yuan Fu]

> On Nov 24, 2021, at 9:18 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
>> If this is true it is a common practice, because all themes I tried so
>> far (about 5) show this behavior.
>> 
>> I inspected nord-theme (1) and it contains
>> 
>> `(mode-line ((,class (:foreground ,nord8 :background ,nord3))))
>> `(mode-line-buffer-id ((,class (:weight bold))))
>> `(mode-line-highlight ((,class (:inherit highlight))))
>> `(mode-line-inactive ((,class (:foreground ,nord4 :background
>> ,nord-uniform-mode-lines-background))))
> 
> Huh.  Odd that they don't inherit from `mode-line' and then override the
> things they don't like, isn't it?

I think that’s just because how `custom-theme-set-faces’ works: it redefines the face rather than modifying it, so any attribute you don’t specify is set to nil instead of left unchanged.

Yuan

Re: Proportional fonts in the mode line (one month test)

[Yuan Fu]

> On Nov 24, 2021, at 9:09 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>>> So far I like it.
>>> 
>>> However, as soon as some theme is activated, the modeline goes back to
>>> monospace. How can I prevent that?
>>> 
>>> To reproduce:
>>> 
>>> emacs -Q
>>> M-x load-theme modus-operandi
>> 
>> I guess the theme set their own face for mode-line which inherited
>> from default which uses a fixed-width font.
> 
> If this is true it is a common practice, because all themes I tried so
> far (about 5) show this behavior.
> 
> I inspected nord-theme (1) and it contains
> 
> `(mode-line ((,class (:foreground ,nord8 :background ,nord3))))
> `(mode-line-buffer-id ((,class (:weight bold))))
> `(mode-line-highlight ((,class (:inherit highlight))))
> `(mode-line-inactive ((,class (:foreground ,nord4 :background ,nord-uniform-mode-lines-background))))
> 
> 1: https://github.com/arcticicestudio/nord-emacs
> 
> 

I don’t think that should be a problem, if a theme wants to use proportional font for mode-line, they can change their definition of mode-line face. And if some one uses a theme with fixed-width mode-line but wants proportional-width mode-line, they can redefine mode-line face.

Yuan

Re: Proportional fonts in the mode line (one month test)

[Yuan Fu]

> On Nov 24, 2021, at 5:53 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> I've now switched master over to defaulting to proportional fonts in the
> mode line.  Customise the `mode-line' face to get the old look back.
> 
> I've made the most obvious things that change size -- the U:-- thing,
> the top/bot, and the line/col thing -- use the `min-width' spec, so
> things should jump around (for those that care about that).
> 
> There's probably more things that should be handled that way, but we'll
> take that as we go along.
> 
> This is just a test: If everybody hates this default, we won't proceed,
> but we won't know unless we test it.  So we're now testing this on the
> trunk for a month.  Vote in a month.

I like the idea and have been using a proportional font because it looks prettier. The only complication is that with proportional font, there is no nontrivial way to right-align some text: In fixed-width environment, you just pad enough spaces, but in proportional environment, you have to pad (space :align-to (- (+ right right-margin) (PIXEL_WIDTH))) where PIXEL_WIDTH = pixel width of the stuff on right. And there is no easy way to calculate the pixel width of a piece of text. I have used some hack that extracted the font object from the face and use font-get-glyphs to calculate glyph width, but that doesn’t always work (you can’t always get a font object from a face).

Yuan

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Yuan Fu <casouri@gmail.com> writes:

> The only complication is that with proportional font,
> there is no nontrivial way to right-align some text: In fixed-width
> environment, you just pad enough spaces, but in proportional
> environment, you have to pad (space :align-to (- (+ right
> right-margin) (PIXEL_WIDTH))) where PIXEL_WIDTH = pixel width of the
> stuff on right.

Yes, I guess right-aligning text on the mode line is pretty hard (unless
you switch to l2r on the mode line)?

> And there is no easy way to calculate the pixel width
> of a piece of text.

There's `string-pixel-width' in Emacs 29 now, and it actually works now
(after Martin's fix yesterdayish 😄).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Yuan Fu]

> On Nov 24, 2021, at 8:55 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>> The only complication is that with proportional font,
>> there is no nontrivial way to right-align some text: In fixed-width
>> environment, you just pad enough spaces, but in proportional
>> environment, you have to pad (space :align-to (- (+ right
>> right-margin) (PIXEL_WIDTH))) where PIXEL_WIDTH = pixel width of the
>> stuff on right.
> 
> Yes, I guess right-aligning text on the mode line is pretty hard (unless
> you switch to l2r on the mode line)?
> 
>> And there is no easy way to calculate the pixel width
>> of a piece of text.
> 
> There's `string-pixel-width' in Emacs 29 now, and it actually works now
> (after Martin's fix yesterdayish 😄).


Fantastic! I pulled the master and it works really well. I remember trying window-text-pixel-size but had some problem with it, I guess Martin fixed that :-D

(defun luna-mode-line-with-padding (text)
  "Return TEXT with padding on the left.
The padding pushes TEXT to the right edge of the mode-line."
  (let* ((len (string-pixel-width text))
         (padding (propertize
                   "-" 'display
                   `(space :align-to
                           (- (+ right right-margin) (,len))))))
    (concat padding text)))

Yuan

Re: Proportional fonts in the mode line (one month test)

[Dmitry Gutov]

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

On 24.11.2021 16:53, Lars Ingebrigtsen wrote:
> This is just a test: If everybody hates this default, we won't proceed,
> but we won't know unless we test it.  So we're now testing this on the
> trunk for a month.  Vote in a month.

I don't mind having a test, but FWIW I don't like the result either.

It's possible that the crux of the matter is that the monospaced font 
has been hand-picked and tweaked over the years, whereas the 
proportional one is something automatically selected by the system.

Comparison screenshot attached.

Speaking in more detail, I probably like how the buffer name is rendered 
and emphasized more, but the modes section (in parens) - not so much.

[-- Attachment #2: Screenshot from 2021-11-24 19-16-57.png --]
[-- Type: image/png, Size: 66546 bytes --]

Re: Proportional fonts in the mode line (one month test)

[Yuan Fu]

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



> On Nov 24, 2021, at 8:51 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 24.11.2021 16:53, Lars Ingebrigtsen wrote:
>> This is just a test: If everybody hates this default, we won't proceed,
>> but we won't know unless we test it.  So we're now testing this on the
>> trunk for a month.  Vote in a month.
> 
> I don't mind having a test, but FWIW I don't like the result either.
> 
> It's possible that the crux of the matter is that the monospaced font has been hand-picked and tweaked over the years, whereas the proportional one is something automatically selected by the system.
> 
> Comparison screenshot attached.
> 
> Speaking in more detail, I probably like how the buffer name is rendered and emphasized more, but the modes section (in parens) - not so much.
> <Screenshot from 2021-11-24 19-16-57.png>

I find the trick of looking nice (for me at least) to be using a sans serif font in light (or ultra light) weight, and add some padding on top and bottom:



Yuan


[-- Attachment #2.1: Type: text/html, Size: 1810 bytes --]

[-- Attachment #2.2: Screen Shot 2021-11-24 at 8.56.37 AM.png --]
[-- Type: image/png, Size: 21334 bytes --]

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 24 Nov 2021 19:51:09 +0300
> 
> It's possible that the crux of the matter is that the monospaced font 
> has been hand-picked and tweaked over the years, whereas the 
> proportional one is something automatically selected by the system.

Most probably.  The font selected here is also but-ugly.  It was OK
for small stretches of text we used variable-pitch until now, but when
the entire mode line is using it, it's just too much, to my
(un)liking.

> Comparison screenshot attached.

Mine is much uglier.

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Most probably.  The font selected here is also but-ugly.  It was OK
> for small stretches of text we used variable-pitch until now, but when
> the entire mode line is using it, it's just too much, to my
> (un)liking.

We should try to pick better proportional fonts, it sounds like.  The
fonts picked on Debian and Macos look pretty good to me, so perhaps this
is mostly a problem on Windows?

>> Comparison screenshot attached.

I thought that looked pretty reasonable?  The bold font is really big,
though -- it looks like a greater difference then the monospace
normal/bold juxtaposition.

> Mine is much uglier.

Could you post a screenshot?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

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

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  emacs-devel@gnu.org
> Date: Wed, 24 Nov 2021 18:26:36 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Most probably.  The font selected here is also but-ugly.  It was OK
> > for small stretches of text we used variable-pitch until now, but when
> > the entire mode line is using it, it's just too much, to my
> > (un)liking.
> 
> We should try to pick better proportional fonts, it sounds like.  The
> fonts picked on Debian and Macos look pretty good to me, so perhaps this
> is mostly a problem on Windows?

How do we pick better proportional fonts, when we don't want to
mention their names in Emacs unless they are free fonts?  Windows
systems usually don't come with free fonts, and installing such fonts
for an unprivileged user becomes harder and harder by the minute in
today's paranoid world with its CISO characters covering their butt by
denying users even the most elementary access rights to their systems.

> > Mine is much uglier.
> 
> Could you post a screenshot?

Attached.


[-- Attachment #2: new-mode-line2.PNG --]
[-- Type: image/png, Size: 2985 bytes --]

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> How do we pick better proportional fonts, when we don't want to
> mention their names in Emacs unless they are free fonts?  Windows
> systems usually don't come with free fonts, and installing such fonts
> for an unprivileged user becomes harder and harder by the minute in
> today's paranoid world with its CISO characters covering their butt by
> denying users even the most elementary access rights to their systems.

Huh.  I thought Microsoft had published a whole bunch of free fonts?  Or
at least that Windows comes with a whole bunch of fonts by default?  (I
don't really know a lot about Windows, fortunately. 😀)

>> > Mine is much uglier.
>> 
>> Could you post a screenshot?
>
> Attached.

Yeah, that was pretty bad.

I haven't knowingly installed any fonts on the Windows VM -- I just
downloaded the OS image and installed it in Parallels.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  emacs-devel@gnu.org
> Date: Wed, 24 Nov 2021 18:58:16 +0100
> 
> >> Could you post a screenshot?
> >
> > Attached.
> 
> Yeah, that was pretty bad.
> 
> I haven't knowingly installed any fonts on the Windows VM -- I just
> downloaded the OS image and installed it in Parallels.

What you see in my screenshot is a font installed on Windows by
default, not something I installed myself.

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> What you see in my screenshot is a font installed on Windows by
> default, not something I installed myself.

And I didn't install any fonts, either, so I'm wondering why our
variable-pitch fonts look so different.  I tested on Windows 11 -- is
that what you're running, too?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 13:37:48 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What you see in my screenshot is a font installed on Windows by
> > default, not something I installed myself.
> 
> And I didn't install any fonts, either, so I'm wondering why our
> variable-pitch fonts look so different.  I tested on Windows 11 -- is
> that what you're running, too?

No, my version is way older.

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Could you post a screenshot?

I tested in my Windows 11 VM on the Apple laptop:


[-- Attachment #2: Screenshot 2021-11-24 at 18.53.23.png --]
[-- Type: image/png, Size: 42500 bytes --]

[-- Attachment #3: Type: text/plain, Size: 121 bytes --]


Looks OK to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Manuel Uberti]

Just to let you know, changing the default font to this:

(custom-set-faces '(variable-pitch ((t (:family "Ubuntu")))))

Makes it look better than what I see on emacs -Q.

FTR, I am running Ubuntu 20.04.

-- 
Manuel Uberti
www.manueluberti.eu

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

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

Manuel Uberti <manuel.uberti@inventati.org> writes:

> Just to let you know, changing the default font to this:
>
> (custom-set-faces '(variable-pitch ((t (:family "Ubuntu")))))
>
> Makes it look better than what I see on emacs -Q.

Could you post some screenshots?  Here's -Q on Debian/bookworm:


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

[-- Attachment #3: Type: text/plain, Size: 21 bytes --]


With your setting:


[-- Attachment #4: Type: image/png, Size: 14419 bytes --]

[-- Attachment #5: Type: text/plain, Size: 143 bytes --]


Just looks smaller to me, not better.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Manuel Uberti]

On 25/11/21 13:39, Lars Ingebrigtsen wrote:
> Manuel Uberti <manuel.uberti@inventati.org> writes:
> 
>> Just to let you know, changing the default font to this:
>>
>> (custom-set-faces '(variable-pitch ((t (:family "Ubuntu")))))
>>
>> Makes it look better than what I see on emacs -Q.
> 
> Could you post some screenshots?  Here's -Q on Debian/bookworm:
> 
> 
> 
> With your setting:
> 
> 
> 
> Just looks smaller to me, not better.
> 

It depends on which font you like more. I prefer the second screenshot with the 
Ubuntu font.

-- 
Manuel Uberti
www.manueluberti.eu

Re: Proportional fonts in the mode line (one month test)

[Tim Cross]

Manuel Uberti <manuel.uberti@inventati.org> writes:

> On 25/11/21 13:39, Lars Ingebrigtsen wrote:
>> Manuel Uberti <manuel.uberti@inventati.org> writes:
>> 
>>> Just to let you know, changing the default font to this:
>>>
>>> (custom-set-faces '(variable-pitch ((t (:family "Ubuntu")))))
>>>
>>> Makes it look better than what I see on emacs -Q.
>> Could you post some screenshots?  Here's -Q on Debian/bookworm:
>> With your setting:
>> Just looks smaller to me, not better.
>> 
>
> It depends on which font you like more. I prefer the second screenshot with the
> Ubuntu font.

I think this is the crux of the matter - in the end, it will come down
to personal taste aesthetics. We are unlikely to find a configuration
which fits all tastes. However, very important to try this test to
identify the issues and see if we can fix them to allow more choice for
the user and make it easier to exercise that choice.

Personally, I use a very large font and I like the variable pitch fonts
for the mode line and header lines (actually, I also like them in
buffers which are 'pros' rather than code and really only want fixed
width for code buffers). It has been very difficult to find a fixed and
variable pitch fonts which are able to work well together, especially at
larger sizes and sticking with free/libre fonts. A lot of trial and
error and willingness to accept some level of ugliness in some
situations.

The big challenge has been in getting consistency. This can be
particularly challenging due to some packages and themes inheriting from
different faces in some interesting combinations.

Re: Proportional fonts in the mode line (one month test)

[Dmitry Gutov]

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

On 24.11.2021 20:22, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Wed, 24 Nov 2021 19:51:09 +0300
>>
>> It's possible that the crux of the matter is that the monospaced font
>> has been hand-picked and tweaked over the years, whereas the
>> proportional one is something automatically selected by the system.
> 
> Most probably.  The font selected here is also but-ugly.  It was OK
> for small stretches of text we used variable-pitch until now, but when
> the entire mode line is using it, it's just too much, to my
> (un)liking.

Although, on that previous screenshot the comparison was done with 
'emacs -Q', meaning it excludes customizations and shows the default 
look on my system (Ubuntu 20.04).

My actual customization looks weirder how: the font became narrower, see 
the attachment.

And this effect can be reached with just

   (set-face-attribute 'default nil :height 110 :family "Inconsolata_dz")

I like the mode-line better on this screenshot, though. *shrug* Just not 
the rest of Emacs.

[-- Attachment #2: Screenshot from 2021-11-24 22-17-46.png --]
[-- Type: image/png, Size: 309834 bytes --]

Re: Proportional fonts in the mode line (one month test)

[Filipp Gunbin]

On 24/11/2021 14:53 +0100, Lars Ingebrigtsen wrote:

> I've now switched master over to defaulting to proportional fonts in the
> mode line.  Customise the `mode-line' face to get the old look back.
>
> I've made the most obvious things that change size -- the U:-- thing,
> the top/bot, and the line/col thing -- use the `min-width' spec, so
> things should jump around (for those that care about that).
>
> There's probably more things that should be handled that way, but we'll
> take that as we go along.

Personally, I'd like the GUI version to support something like tty
emulation mode, where everything looks the same as on tty, including a
single monospaced font (it's just easier for me to read technical stuff
in monospaced fonts), but with image support.  But that's me.

RE: [External] : Proportional fonts in the mode line (one month test)

[Drew Adams]

> I've now switched master over to defaulting to proportional fonts in the
> mode line.  Customise the `mode-line' face to get the old look back.
> 
> I've made the most obvious things that change size -- the U:-- thing,
> the top/bot, and the line/col thing -- use the `min-width' spec, so
> things should jump around (for those that care about that).
> 
> There's probably more things that should be handled that way, but we'll
> take that as we go along.
> 
> This is just a test: If everybody hates this default, we won't proceed,
> but we won't know unless we test it.  So we're now testing this on the
> trunk for a month.  Vote in a month.

I don't build Emacs, so can't see or tell just what you
changed.  But FWIW I've used a variable-pitch face for
`mode-line' for some time now, with no problems.

I just use this face setting for it:

((t (:inherit variable-pitch :background "PaleGoldenrod"
     :foreground "black"
     :box (:line-width -1 :style released-button))))

What have you changed, other than the font and, I guess,
some alignments?

Why change the default?  Isn't it easy enough for users
to customize to get the changes you're proposing?

Re: [External] : Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> What have you changed, other than the font and, I guess,
> some alignments?

That's it.

> Why change the default?  Isn't it easy enough for users
> to customize to get the changes you're proposing?

No, Emacs should have a good out-of-the-box experience.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now switched master over to defaulting to proportional fonts in the
> mode line.  Customise the `mode-line' face to get the old look back.

There must be a better way to achieve this than modifying the
`mode-line' face.  We could probably set the face separately for
individual parts of `mode-line-format'.

Many external packages depend on a fixed pitch `mode-line' face.  It
would be good to not change this default.

> I've made the most obvious things that change size -- the U:-- thing,
> the top/bot, and the line/col thing -- use the `min-width' spec, so
> things should jump around (for those that care about that).

Also, please don't change the header line as well.  For instance, the
header line in calc that reads "---- Emacs Calculator Mode ----" is now
totally broken.

There are also packages that override mode-line-format entirely, such as
2C, and they now look bad.

> There's probably more things that should be handled that way, but we'll
> take that as we go along.

> This is just a test: If everybody hates this default, we won't
> proceed,

This wording is shocking!  Does it mean that we will proceed with this
default if even one person likes it?

> but we won't know unless we test it.  So we're now testing this on the
> trunk for a month.

I don't think we should make master a place for treating users as guinea
pigs, especially when the change cannot be easily reverted (how do I get
rid of the new `min-width' properties in mode-line-format).

> Vote in a month.

This should be posted to info-gnu-emacs.  Not everyone who uses Emacs
follows Emacs development, and any kind of vote posted only to
emacs-devel is likely going to come out skewed.

Thanks.

Re: Proportional fonts in the mode line (one month test)

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> I've now switched master over to defaulting to proportional fonts in the
>> mode line.  Customise the `mode-line' face to get the old look back.

This also makes the CR/LF toggle impossible to click.

Re: Proportional fonts in the mode line (one month test)

[Jim Porter]

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

On 11/24/2021 4:39 PM, Po Lu wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
>>> I've now switched master over to defaulting to proportional fonts in the
>>> mode line.  Customise the `mode-line' face to get the old look back.
> 
> This also makes the CR/LF toggle impossible to click.

Yeah, if nothing else, the U:--- thing (I'm sure it has an actual 
name...) should be fixed-width. See the attached image for how tiny the 
CR/LF toggle is now. It's highlighted with the box just after the U.

- Jim

[-- Attachment #2: very-narrow.png --]
[-- Type: image/png, Size: 1214 bytes --]

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Jim Porter <jporterbugs@gmail.com> writes:

> Yeah, if nothing else, the U:--- thing (I'm sure it has an actual
> name...) should be fixed-width. See the attached image for how tiny
> the CR/LF toggle is now. It's highlighted with the box just after the
> U.

Yes, that should be fixed.  Hm...  We could use m-dashes instead of
hyphens, I guess?  It'd be more work to have a different definition on
GUI and TUI, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 25 Nov 2021 14:29:41 +0100
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> 
> Jim Porter <jporterbugs@gmail.com> writes:
> 
> > Yeah, if nothing else, the U:--- thing (I'm sure it has an actual
> > name...) should be fixed-width. See the attached image for how tiny
> > the CR/LF toggle is now. It's highlighted with the box just after the
> > U.
> 
> Yes, that should be fixed.  Hm...  We could use m-dashes instead of
> hyphens, I guess?  It'd be more work to have a different definition on
> GUI and TUI, though.

Using hyphens might mean Emacs will use a font different from the
default one used by variable-pitch, if that default font happens not
to support that character (not very probably, but not impossible).

Re: Proportional fonts in the mode line (one month test)

[Jim Porter]

On 11/25/2021 5:29 AM, Lars Ingebrigtsen wrote:
> Jim Porter <jporterbugs@gmail.com> writes:
> 
>> Yeah, if nothing else, the U:--- thing (I'm sure it has an actual
>> name...) should be fixed-width. See the attached image for how tiny
>> the CR/LF toggle is now. It's highlighted with the box just after the
>> U.
> 
> Yes, that should be fixed.  Hm...  We could use m-dashes instead of
> hyphens, I guess?  It'd be more work to have a different definition on
> GUI and TUI, though.

That might help, but is there also a "wide colon" character we could use 
for the CR/LF indicator?

There's a further problem I've noticed with using variable-width fonts 
here though: suppose I want to toggle the "buffer modified" state but 
then change my mind and want to undo it. Normally, I'd just click the 
second hyphen, and then click again to toggle back to "unmodified". 
However, with variable-width fonts, the "*" is typically wider than the 
"-". Depending on the font and where exactly I place my mouse cursor, 
it's possible for me to click on the second hyphen to set the buffer as 
modified, which changes the "read only" indicator to a "*" as well, 
shifting everything to the right slightly so that now, even though my 
mouse hasn't moved, it's hovering over the "read only" indicator. Thus, 
I can't just click again to reset to "unmodified". I'd have to move my 
mouse cursor slightly to the right and *then* click.

Even more confusingly, if I don't move the mouse after clicking on the 
"buffer modified" indicator, Emacs still shows the box around *that* 
indicator, despite the fact that when I click, it will actually toggle 
the "read only" indicator.

- Jim

Re: Proportional fonts in the mode line (one month test)

[Kévin Le Gouguec]

Jim Porter <jporterbugs@gmail.com> writes:

> On 11/25/2021 5:29 AM, Lars Ingebrigtsen wrote:
>> Jim Porter <jporterbugs@gmail.com> writes:
>> 
>>> Yeah, if nothing else, the U:--- thing (I'm sure it has an actual
>>> name...) should be fixed-width. See the attached image for how tiny
>>> the CR/LF toggle is now. It's highlighted with the box just after the
>>> U.
>> Yes, that should be fixed.  Hm...  We could use m-dashes instead of
>> hyphens, I guess?  It'd be more work to have a different definition on
>> GUI and TUI, though.
>
> That might help, but is there also a "wide colon" character we could
> use for the CR/LF indicator?

I'm sure this is a silly idea, but…

Would it be possible to double down on the min-width specs, i.e. set the
min-width of each individual piece of "the U:---" thing to something
large enough to be clickable, despite the indicator char being narrow?

I'm not sure (1) this is possible (can the clickable area cover the
whole width given by min-width, or can it only be as wide as the
underlying char?)  (2) this is desirable (this would effectively pad
variable-width characters to display them at a fixed width… but at least
we wouldn't mix fonts?) (3) this is advisable (something something
performance?)…

(I tried messing around with e.g. mode-line-mule-info to make a POC of
this, to no avail; not sure if this means it's not possible or I should
get some sleep.  I'll test the latter hypothesis first)

Re: Proportional fonts in the mode line (one month test)

[Jim Porter]

On 11/25/2021 3:04 PM, Kévin Le Gouguec wrote:
> Jim Porter <jporterbugs@gmail.com> writes:
> 
>> That might help, but is there also a "wide colon" character we could
>> use for the CR/LF indicator?
> 
> I'm sure this is a silly idea, but…
> 
> Would it be possible to double down on the min-width specs, i.e. set the
> min-width of each individual piece of "the U:---" thing to something
> large enough to be clickable, despite the indicator char being narrow?

If the goal is to have Emacs take advantage of its rendering 
capabilities when run as a graphical application so that it doesn't just 
look like a terminal window, another option might be to use icons for 
each element in the U:--- thing. SVGs would be easy to scale for various 
resolutions/pixel densities and still ensure that they're relatively 
easy to click. It may also be possible to make icons that are more 
"obvious"; I doubt most novices could tell you what each of the 
characters in U:--- mean.

On the other hand, that's significantly more effort than other 
solutions, unless someone happens to have appropriate icons sitting 
around waiting to be used.

- Jim

Re: Proportional fonts in the mode line (one month test)

[Yuan Fu]

> 
> If the goal is to have Emacs take advantage of its rendering capabilities when run as a graphical application so that it doesn't just look like a terminal window, another option might be to use icons for each element in the U:--- thing. SVGs would be easy to scale for various resolutions/pixel densities and still ensure that they're relatively easy to click. It may also be possible to make icons that are more "obvious"; I doubt most novices could tell you what each of the characters in U:--- mean.
> 
> On the other hand, that's significantly more effort than other solutions, unless someone happens to have appropriate icons sitting around waiting to be used.

That’s a good idea. I never remembered which dash means what, using icons will make U:--- much more useful for new users.

Yuan

Re: Proportional fonts in the mode line (one month test)

[Po Lu]

Jim Porter <jporterbugs@gmail.com> writes:

> are more "obvious"; I doubt most novices could tell you what each of
> the characters in U:--- mean.

This is why we have tooltips there, right?

Re: Proportional fonts in the mode line (one month test)

[Yuri Khan]

On Fri, 26 Nov 2021 at 06:05, Kévin Le Gouguec
<kevin.legouguec@gmail.com> wrote:

> Would it be possible to double down on the min-width specs, i.e. set the
> min-width of each individual piece of "the U:---" thing to something
> large enough to be clickable, despite the indicator char being narrow?

This is exactly how any other application would approach this. We have
five orthogonal properties — so put five fixed width buttons. Assign
an icon or a Unicode emoji/dingbat to each state and arrange for them
to fit the button interior size.

Re: Proportional fonts in the mode line (one month test)

[Po Lu]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> I'm sure this is a silly idea, but…
>
> Would it be possible to double down on the min-width specs, i.e. set the
> min-width of each individual piece of "the U:---" thing to something
> large enough to be clickable, despite the indicator char being narrow?

IMO, the correct solution would be to go back to a monospace mode-line,
or, failing that, a monospace coding system indicator.

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Would it be possible to double down on the min-width specs, i.e. set the
> min-width of each individual piece of "the U:---" thing to something
> large enough to be clickable, despite the indicator char being narrow?

`min-width' currently doesn't support nested declarations, but it would
be possible to add that.  On the other hand, perhaps there should just
be another spec for doing that particular thing -- the monospacification
thing I talked about earlier.

The one wrinkle here, though, is that in this case, one of the
characters used here -- "%" -- is usually much wider than the "normal
character width", so ensuring no movement at all would mean that the "-"
would be surrounded by a lot of space.

But just making the "-" take up at least as much space as the "normal
character width" would be trivial.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Jim Porter]

On 11/26/2021 4:35 AM, Lars Ingebrigtsen wrote:
> The one wrinkle here, though, is that in this case, one of the
> characters used here -- "%" -- is usually much wider than the "normal
> character width", so ensuring no movement at all would mean that the "-"
> would be surrounded by a lot of space.

This points to a similar problem I mentioned, but in reverse: If a 
buffer is currently read-only and I click the first "%", it will change 
to "-"[1] and thus become narrower. Depending on where my mouse pointer 
is, that could mean it's now hovering over the "modified" indicator, so 
if I click again, I end up changing the "modified" state, not the 
"read-only" state.

I think for a series of consecutive buttons, we should do whatever we 
can to ensure that they don't shift positions unnecessarily, and 
especially not when clicking on them. Whether this is ensured by 
:min-width/:max-width specifications, monospace fonts, or using (SVG) 
icons doesn't matter too much, so long as the buttons aren't shifting 
around. A monospace font does have the advantage of being the easiest 
solution though; it Just Works today.

- Jim

[1] Assuming the buffer is unmodified.

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 08:39:57 +0800
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> >> I've now switched master over to defaulting to proportional fonts in the
> >> mode line.  Customise the `mode-line' face to get the old look back.
> 
> This also makes the CR/LF toggle impossible to click.

Is it really "impossible" with the font you get on your system?  Here
I can click it, although it's indeed very narrow, so needs precision
of the mouse.

Re: Proportional fonts in the mode line (one month test)

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Is it really "impossible" with the font you get on your system?

See below, thanks.

> Here I can click it, although it's indeed very narrow, so needs
> precision of the mouse.

Well, how narrow it is on my system significantly impedes my ability to
hit it with the mouse, to the point at which I might as well set the
coding system manually, instead of toggling it through the mode line.

It takes me around 5 seconds to click the toggle now, something I was
able to do instantaneously.

Thanks.

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> There must be a better way to achieve this than modifying the
> `mode-line' face.  We could probably set the face separately for
> individual parts of `mode-line-format'.
>
> Many external packages depend on a fixed pitch `mode-line' face.  It
> would be good to not change this default.

Well, that's up to the package authors to decide.

> Also, please don't change the header line as well.  For instance, the
> header line in calc that reads "---- Emacs Calculator Mode ----" is now
> totally broken.

Right, like Juri said:

(defface header-line
  '((default
     :inherit mode-line)

I wasn't aware of that, and I think the right fix here is to remove this
inheritance -- I don't see any good reason to have this coupling between
the mode line and the header lines.  Any opinions?

>> This is just a test: If everybody hates this default, we won't
>> proceed,
>
> This wording is shocking!  Does it mean that we will proceed with this
> default if even one person likes it?

Sometimes you don't have to use predicate logic on natural language.

So: No.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 25 Nov 2021 14:28:29 +0100
> Cc: emacs-devel@gnu.org
> 
> > Also, please don't change the header line as well.  For instance, the
> > header line in calc that reads "---- Emacs Calculator Mode ----" is now
> > totally broken.
> 
> Right, like Juri said:
> 
> (defface header-line
>   '((default
>      :inherit mode-line)
> 
> I wasn't aware of that, and I think the right fix here is to remove this
> inheritance -- I don't see any good reason to have this coupling between
> the mode line and the header lines.  Any opinions?

I'd expect removing the inheritance to produce no less breakage, as
many packages and customizations have no doubt grown to rely on that.

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd expect removing the inheritance to produce no less breakage, as
> many packages and customizations have no doubt grown to rely on that.

Perhaps we should introduce a new intermediary face just for the mode
line -- i.e., `mode-line-display', and have that inherit from
`mode-line'.  (And then revert the change to `mode-line' and put it in
`mode-line-display' instead, and use `mode-line-display' for the mode
line.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Perhaps we should introduce a new intermediary face just for the mode
> line -- i.e., `mode-line-display', and have that inherit from
> `mode-line'.  (And then revert the change to `mode-line' and put it in
> `mode-line-display' instead, and use `mode-line-display' for the mode
> line.)

I've now done this.  The new face actually used on the mode lines is
called `mode-line-active', and is the one that inherits from
variable-pitch.  This fixes the issue with the inadverdant inheritance
by header-line (and I'm use other things that inherit from mode-line).

This also means that you now have to say

  (set-face-attribute 'mode-line-active nil :inherit 'mode-line)
  (set-face-attribute 'mode-line-inactive nil :inherit 'mode-line)

to revert to non-proportional fonts.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Protesilaos Stavrou]

On 2021-11-24, 14:53 +0100, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> I've now switched master over to defaulting to proportional fonts in the
> mode line.  Customise the `mode-line' face to get the old look back.

Thank you for starting this thread!

Can this and every other use of 'variable-pitch' that is being discussed
in recent threads be made optional?

The notion that such fonts look prettier is only true with specific font
combinations at particular point sizes.  I have experimented with many
variable-pitch font families and I seldom like how they combine with my
default/fixed-pitch typeface (let's call this a "mixed fonts" case).

Even the likes of DejaVu Sans and DejaVu Sans Mono are inconsistent when
used together, because the former has a heavier bold weight than the
latter (at least at certain point sizes).  Other families like Ubuntu
and Ubuntu Mono have different visual heights at certain point sizes
(one looks smaller---whether the actual box of the glyph is smaller does
not matter to what is seen).

The general constraint with mixed fonts is that the heights and overall
design character of the two typefaces seldom coincide.  So in this
scenario the mode-line will be a bit taller/shorter than a regular line
in the buffer and/or it will feel out of place if the design of the
glyphs is different.

My point is on the visual aspects of how things look, as I consider
consistency a matter of aesthetics (things look prettier to me when they
have no inconsistencies).

> I've made the most obvious things that change size -- the U:-- thing,
> the top/bot, and the line/col thing -- use the `min-width' spec, so
> things should jump around (for those that care about that).
>
> There's probably more things that should be handled that way, but we'll
> take that as we go along.
>
> This is just a test: If everybody hates this default, we won't proceed,
> but we won't know unless we test it.  So we're now testing this on the
> trunk for a month.  Vote in a month.

My opinion is that every use of variable-pitch for the mode-line,
header-line, headings, Help buffers, Info breadcrumbs, etc. should be
optional.  Whether opt-in or opt-out is not a major issue.

-- 
Protesilaos Stavrou
https://protesilaos.com

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Protesilaos Stavrou <info@protesilaos.com>
> Date: Thu, 25 Nov 2021 08:26:14 +0200
> Cc: emacs-devel@gnu.org
> 
> The general constraint with mixed fonts is that the heights and overall
> design character of the two typefaces seldom coincide.  So in this
> scenario the mode-line will be a bit taller/shorter than a regular line
> in the buffer and/or it will feel out of place if the design of the
> glyphs is different.

In all fairness, the mode line is already taller than a regular line
with buffer text, because the mode line has the :box face.

I do agree with the general point you make about mixing different
typefaces.

Re: Proportional fonts in the mode line (one month test)

[Gregory Heytings]

>
> In all fairness, the mode line is already taller than a regular line 
> with buffer text, because the mode line has the :box face.
>

The _default_ mode line, yes.  But it's easy to turn that off with 
(set-face-attribute 'mode-line nil :box nil).

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Protesilaos Stavrou <info@protesilaos.com> writes:

> Can this and every other use of 'variable-pitch' that is being discussed
> in recent threads be made optional?

Just set `variable-pitch' to `fixed-pitch' if you don't want anything to
be proportional.

> My point is on the visual aspects of how things look, as I consider
> consistency a matter of aesthetics (things look prettier to me when they
> have no inconsistencies).

Yes, making the font mixes be more consistent across all platforms is a
challenge.  But it seems to work pretty well out of the box on a large
number of systems.  The main challenge seems to be that people have
already customised their variable-pitch fonts manually, probably because
we don't currently mix fonts a lot.

> My opinion is that every use of variable-pitch for the mode-line,
> header-line, headings, Help buffers, Info breadcrumbs, etc. should be
> optional.  Whether opt-in or opt-out is not a major issue.

Yes, of course.  All these things are defined via faces, and users can
customise the faces as they wish.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Simen Heggestøyl]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now switched master over to defaulting to proportional fonts in the
> mode line.  Customise the `mode-line' face to get the old look back.

Looks pretty nice here out of the box.

However the mode name part now changes position based on the width of
the buffer position text when jumping around in a buffer, which looks
kind of jarring to me.

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Simen Heggestøyl <simenheg@runbox.com> writes:

> However the mode name part now changes position based on the width of
> the buffer position text when jumping around in a buffer, which looks
> kind of jarring to me.

Yes, I'm debugging that currently.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Simen Heggestøyl <simenheg@runbox.com> writes:
>
>> However the mode name part now changes position based on the width of
>> the buffer position text when jumping around in a buffer, which looks
>> kind of jarring to me.
>
> Yes, I'm debugging that currently.

I've added a workaround for this to the trunk while trying to find a
permanent solution.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Michael Welsh Duggan]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now switched master over to defaulting to proportional fonts in the
> mode line.  Customise the `mode-line' face to get the old look back.
>
> I've made the most obvious things that change size -- the U:-- thing,
> the top/bot, and the line/col thing -- use the `min-width' spec, so
> things should jump around (for those that care about that).
>
> There's probably more things that should be handled that way, but we'll
> take that as we go along.
>
> This is just a test: If everybody hates this default, we won't proceed,
> but we won't know unless we test it.  So we're now testing this on the
> trunk for a month.  Vote in a month.

I tried this for the first time today, and I'm seeing a large space
after the between the character-set colon identifiers and the buffer
modification indicators.  I include before/after images.

Before:

[-- Attachment #2: Screenshot from 2021-11-29 09-40-07.png --]
[-- Type: image/png, Size: 5183 bytes --]

[-- Attachment #3: Type: text/plain, Size: 8 bytes --]


After:

[-- Attachment #4: Screenshot from 2021-11-29 09-39-49.png --]
[-- Type: image/png, Size: 6233 bytes --]

[-- Attachment #5: Type: text/plain, Size: 42 bytes --]


-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Michael Welsh Duggan <mwd@md5i.com>
> Date: Mon, 29 Nov 2021 09:52:21 -0500
> Cc: emacs-devel@gnu.org
> 
> I tried this for the first time today, and I'm seeing a large space
> after the between the character-set colon identifiers and the buffer
> modification indicators.

Seems like the "@" thingy on client frames' mode-line causes the
preceding mode-line-mule-info to be padded to 5-char width, for some
reason.

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I tried this for the first time today, and I'm seeing a large space
>> after the between the character-set colon identifiers and the buffer
>> modification indicators.
>
> Seems like the "@" thingy on client frames' mode-line causes the
> preceding mode-line-mule-info to be padded to 5-char width, for some
> reason.

Hm...  could this be the same Lisp/C-string `min-width' glitch we've
been discussing?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Jim Porter]

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

On 11/24/2021 5:53 AM, Lars Ingebrigtsen wrote:
> I've now switched master over to defaulting to proportional fonts in the
> mode line.  Customise the `mode-line' face to get the old look back.
> 
> I've made the most obvious things that change size -- the U:-- thing,
> the top/bot, and the line/col thing -- use the `min-width' spec, so
> things should jump around (for those that care about that).

Not sure whether to file a bug for this or just mention it here, but it 
seems that the `min-width' spec interacts poorly with 
`mode-line-client', which displays an "@" immediately after the colon in 
the U:--- thing for emacsclient frames. Normally, this would look like 
"U:@---", but now it looks like "U:    @---". See the attached image.

To see this in action yourself, you can run:

   emacs -Q --daemon
   emacsclient -c foo.txt

Looking at the values for `mode-line-format' and `mode-line-client', I 
think this may be because both use `:propertize', and this causes some 
confusion internally?

- Jim

[-- Attachment #2: mode-line-client-too-wide.png --]
[-- Type: image/png, Size: 7434 bytes --]

Re: Proportional fonts in the mode line (one month test)

[Davide Masserut]

Jim Porter <jporterbugs@gmail.com> writes:

> Not sure whether to file a bug for this or just mention it here, but it 
> seems that the `min-width' spec interacts poorly with 
> `mode-line-client', which displays an "@" immediately after the colon in 
> the U:--- thing for emacsclient frames. Normally, this would look like 
> "U:@---", but now it looks like "U:    @---". See the attached image.

The bug report is here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52183

Re: Proportional fonts in the mode line (one month test)

[Eric S Fraga]

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

Finally got around to building/installing the latest version of Emacs
from git.

Generally, I don't mind the proportional font for the mode line
although, at least with my settings, the typography seems strange in
some cases.  For instance, see attached image where the hyphen merges
with the following letter e.  I am not sure this is what should be
happening although I don't use proportional fonts often.

-- 
Eric S Fraga with org 9.5.1 in Emacs 29.0.50 on Debian 11.1

[-- Attachment #2: screendump-20211201122652.png --]
[-- Type: image/png, Size: 3632 bytes --]

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> For instance, see attached image where the hyphen merges
> with the following letter e.

What bit of the mode line is that?  (Perhaps you can post a screenshot
of the entire mode line.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Eric S Fraga]

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

On Wednesday,  1 Dec 2021 at 14:41, Lars Ingebrigtsen wrote:
> What bit of the mode line is that?  (Perhaps you can post a screenshot
> of the entire mode line.)

It's part of the file (buffer) name (name generated by org roam).
Attached screenshot shows most of the mode line.

Thank you,
eric

-- 
Eric S Fraga with org 9.5.1 in Emacs 29.0.50 on Debian 11.1

[-- Attachment #2: screendump-20211201134439.png --]
[-- Type: image/png, Size: 16170 bytes --]

Re: Proportional fonts in the mode line (one month test)

[Lars Ingebrigtsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> It's part of the file (buffer) name (name generated by org roam).
> Attached screenshot shows most of the mode line.

I see.  So I'd assume evalling the following also has the same overlap?

(insert (propertize "foo-emacs" 'face 'variable-pitch))

In which case it sounds like your proportional font just is that way.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Proportional fonts in the mode line (one month test)

[Eric S Fraga]

On Wednesday,  1 Dec 2021 at 14:54, Lars Ingebrigtsen wrote:
> I see.  So I'd assume evalling the following also has the same overlap?
>
> (insert (propertize "foo-emacs" 'face 'variable-pitch))

trying this in my scratch buffer displays the text using normal
monospaced font.  In any case, I created another buffer and changed it
to proportional font and yes it has a very similar appearance, albeit
maybe with a single pixel gap.  (different background etc. maybe making
it appear subtly different.)

> In which case it sounds like your proportional font just is that way.

Yes, definitely.  I'm using:

ftcrhb:-PfEd-UnVada-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1 (#x10)

I have tried a different font (Carlito) for variable pitch and it does
look better for this aspect.  I don't like that font as much overall,
mind you.  I haven't really spent much time trying to find a good
proportional font to date.  Something for when I'm seriously bored, I
guess. 😉

So the choice of font for variable pitch has an impact, which is kind of
obvious and which has already been highlighted in this thread...

thank you,
eric

-- 
Eric S Fraga with org 9.5.1 in Emacs 29.0.50 on Debian 11.1

Re: Proportional fonts in the mode line (one month test)

[Eli Zaretskii]

> From: Eric S Fraga <e.fraga@ucl.ac.uk>
> Date: Wed, 01 Dec 2021 14:19:41 +0000
> Cc: emacs-devel@gnu.org
> 
> On Wednesday,  1 Dec 2021 at 14:54, Lars Ingebrigtsen wrote:
> > I see.  So I'd assume evalling the following also has the same overlap?
> >
> > (insert (propertize "foo-emacs" 'face 'variable-pitch))
> 
> trying this in my scratch buffer displays the text using normal
> monospaced font.

You need to turn off font-lock, because otherwise no 'face' property
can have any effect.

Re: Proportional fonts in the mode line (one month test)

[Eric S Fraga]

On Wednesday,  1 Dec 2021 at 09:40, Eli Zaretskii wrote:
> You need to turn off font-lock, because otherwise no 'face' property
> can have any effect.

😳 ah, yes, of course.

So, the interesting thing is that there is a single pixel (give or take
-- the problem with high resolution displays) between the - and the e
but this is not noticeable with a light background and only just visible
with a dark background.

So I might have to search for a nicer proportional font...

thank you,
eric

-- 
Eric S Fraga with org 9.5.1 in Emacs 29.0.50 on Debian 11.1

Re: Proportional fonts in the mode line (one month test)

[João Pedro de Amorim Paula]

On 01 December 2021 14:45, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:

> So I might have to search for a nicer proportional font...

May I suggest you take a look into Iosevka's[1] proportional width
fonts? They are "quasi-proportional", so they retain some characters as
monospaced. I've been using Iosevka Aile as my variable-width font, with
proportional fonts enabled in the mode line, and I must say it looks
great!

They also offer a great number of variants, and you can whip up your own
personal Iosevka by customizing (almost) every character. Protesilaos
also has his own variant of Iosevka, called Iosevka Comfy [2] which is
also worth checking out.

[1] <https://typeof.net/Iosevka/>
[2] <https://gitlab.com/protesilaos/iosevka-comfy>

-- 
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: Proportional fonts in the mode line (one month test)

[Eric S Fraga]

On Friday,  3 Dec 2021 at 00:09, João Pedro de Amorim Paula wrote:
> May I suggest you take a look into Iosevka's[1] proportional width
> fonts? 

I will have a look.  Thank you.

-- 
Eric S Fraga with org 9.5.1 in Emacs 29.0.50 on Debian 11.1

Re: Proportional fonts in the mode line (one month test)

[Richard Stallman]

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

  > May I suggest you take a look into Iosevka's[1] proportional width
  > fonts? They are "quasi-proportional", so they retain some characters as
  > monospaced. I've been using Iosevka Aile as my variable-width font, with
  > proportional fonts enabled in the mode line, and I must say it looks
  > great!

It sounds nice.  What license do they carry?


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

Re: Proportional fonts in the mode line (one month test)

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > May I suggest you take a look into Iosevka's[1] proportional width
>   > fonts? They are "quasi-proportional", so they retain some characters as
>   > monospaced. I've been using Iosevka Aile as my variable-width font, with
>   > proportional fonts enabled in the mode line, and I must say it looks
>   > great!
>
> It sounds nice.  What license do they carry?

Apparently, they use version 1.1 of the SIL OFL.

Re: Proportional fonts in the mode line (one month test)

[Eric S Fraga]

On Friday,  3 Dec 2021 at 00:09, João Pedro de Amorim Paula wrote:
> May I suggest you take a look into Iosevka's[1] proportional width
> fonts? They are "quasi-proportional", so they retain some characters as
> monospaced. 

Playing with them now.  Quite nice, I must say.  I'm using Aile for the
proportional (quasi-, as you say) but Etoile is good as well.

Thank you,
eric
-- 
Eric S Fraga with org 9.5.1 in Emacs 29.0.50 on Debian 11.1

Re: Proportional fonts in the mode line (one month test)

[James Cloos]

i updated to latest master to give this a try.

but didn't see any difference.

then i figured out why; ages ago i customized that face to include:

 :family "DejaVu Serif"

😊

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: Proportional fonts in the mode line (one month test)

[João Pedro de Amorim Paula]

On 05 December 2021 13:04, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:

> Playing with them now.  Quite nice, I must say.  I'm using Aile for the
> proportional (quasi-, as you say) but Etoile is good as well.

I use Etoile when I have to do some sort of presentation with TeX
previews in Org-mode, because it looks better with Computer Modern. In a
bit of a side note, I've tried using Computer Modern itself, but the
vertical spacing of the characters was way too much; don't know if it
was just the TTF version I got, and I also don't know how to edit fonts
in order to make it smaller.

> Thank you,
> eric

You're welcome! Glad to help.

-- 
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: Proportional fonts in the mode line (one month test)

[Yuri Khan]

On Wed, 1 Dec 2021 at 20:52, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> It's part of the file (buffer) name (name generated by org roam).
> Attached screenshot shows most of the mode line.

Are you sure your font actually has a bold weight? It looks like
synthetic bold in the screenshot.

Re: Proportional fonts in the mode line (one month test)

[Eric S Fraga]

On Wednesday,  1 Dec 2021 at 22:00, Yuri Khan wrote:
> Are you sure your font actually has a bold weight? It looks like
> synthetic bold in the screenshot.

No idea but could very well be that it doesn't have such.  Not sure how
to check.  The whole font side of Emacs is much of a mystery to me.  I
just seem to have fallen into using some fonts along the way...

As already noted in this thread, it will be useful for a set of fonts to
be suggested to users but this is difficult due to the different
availability on different operating systems.  I would welcome
suggestions for proportional fonts, available for Debian, that would
work well in conjunction with JuliaMono as the monospaced font...

-- 
Eric S Fraga with org 9.5.1 in Emacs 29.0.50 on Debian 11.1