Automatically add italics for fonts which don't support them

[ruffson]

I have absolutely no idea how exactly font rendering works, so if this is a request too crazy, please disregard it.

Is your feature request related to a problem? Please describe.
There some nice fonts which do not have an italics style such as Cascadia (or the nerd font version CaskaydiaCove which I use).

Describe the solution you'd like
It would be nice if Wezterm could automatically add support for italics like e.g. Sublime Text does.

Describe alternatives you've considered
Using fonts which have italics, but Cascadia is quite nice in other aspects. Italics would be quite nice for more expressiveness.

Additional context
Attached I added two screenshots of the same code with the same font (CaskaydiaCove) and font size. The first one is Sublime Text 3 which adds italics and the second is wezterm with neovim.

[wez]

Give it ~30 minutes to build and try the nightly!

[ruffson]

Damn you are on fire! Thank you so much!! The work you do is much appreciated.

[ruffson]

Just one thing @wez after trying out the nightly for a bit I had now two occasions where wez would completely hang. Nothing I could do to get it to close besides kill/killall is that a known problem with a new feature in nightly or even this font change?
This happened once inside neovim and once just without running any program when I closed another opened wezterm window (on Fedore 34, X11).

[wez]

If you can get that to reproduce then it would be great to capture a stack trace to see where it is stuck:

gdb -p PID
thread apply all bt

Where PID is the process of the stuck wezterm

[ruffson]

If you can get that to reproduce then it would be great to capture a stack trace to see where it is stuck:

gdb -p PID
thread apply all bt

Where PID is the process of the stuck wezterm

Sure here it is. I could kinda reproduce it by having two wezterm windows open, and in one I change the theme and font a few times and then when I close one of them, the other one halts. But not super deterministicly/

gdb.log

[wez]

Thanks; that trace doesn't appear to be a classic hang; it just appears as though everything is idle and waiting for something to happen.

Try starting wezterm with tracing turned on: WEZTERM_LOG=trace wezterm 2> /tmp/wezterm.txt, reproducing the issue and getting the trace to me. Note that that trace will contain information about all input and output in the traced session, so don't do anything in there that requires typing a password or that might reveal something sensitive about your system!

[ruffson]

Thanks; that trace doesn't appear to be a classic hang; it just appears as though everything is idle and waiting for something to happen.

Try starting wezterm with tracing turned on: WEZTERM_LOG=trace wezterm 2> /tmp/wezterm.txt, reproducing the issue and getting the trace to me. Note that that trace will contain information about all input and output in the traced session, so don't do anything in there that requires typing a password or that might reveal something sensitive about your system!

Hmm this time when I reproduced a hang there was nothing logged to tmp. I'll try this again a few times.

Curiously with only this one open dead window, there are other processes showing up with regards to wezterm. (I am currently using a neovim as an appimage unttil it made its way to Fedora repos):
(Just for clarification, I am calling the commands below from a kitty terminal)

base ❯ procs wezterm
 PID:▲   User │ TTY    CPU MEM CPU Time │ Command
              │        [%] [%]          │
 3019760 raph │ pts/18 0.0 0.1 00:00:01 │ /tmp/.mount_nvim.a6SlNoU/usr/bin/nvim /home/raph/.dotfiles/wezterm.lua
 3019763 raph │        0.0 0.0 00:00:00 │ /home/raph/Applications/nvim.appimage /home/raph/.dotfiles/wezterm.lua
 3058433 raph │        0.0 0.0 00:00:00 │ bash -c WEZTERM_LOG=trace wezterm 2> /tmp/wezterm.txt
 3058436 raph │        0.0 0.4 00:00:13 │ /usr/bin/wezterm-gui
 3062160 raph │        0.0 0.0 00:00:00 │ /home/raph/Applications/nvim.appimage /home/raph/.dotfiles/wezterm.lua
 3065713 raph │ pts/19 0.0 0.1 00:00:00 │ /tmp/.mount_nvim.a9a0Nag/usr/bin/nvim /home/raph/.dotfiles/wezterm.lua
 3065716 raph │        0.0 0.0 00:00:00 │ /home/raph/Applications/nvim.appimage /home/raph/.dotfiles/wezterm.lua

~
base ❯ ll /tmp/ | rg wezterm.txt

Here is a short video of the dead window, note how the cursor (coming from the left) disappears when moving over the window. No keys are accepted and the window cannot even be closed when activating GNOME's activities overview.

wez_not_responding.mp4

[ruffson]

I have a log now after I killed these processes, not sure if that helps.
This is the order how I killed them:

kill -9 3019760
kill -9 3058433
killall wezterm-gui

The log:
wezterm.txt

[wez]

Is that log file from the same session as your latest recording? The timestamps in the log seem to end many minutes before the video.

Towards the bottom of the file:

 2021-05-23T16:14:04.707Z DEBUG mux                                 > removing pane 0
 2021-05-23T16:14:04.707Z DEBUG mux                                 > killing pane 0
 2021-05-23T16:14:04.707Z DEBUG mux::localpane                      > killing process in pane 0, state is Dead
 2021-05-23T16:14:04.707Z TRACE wezterm_gui::frontend               > Mux is now empty, terminate gui

it looks like wezterm thought that everything was done; it would typically terminate and close its windows at that point.

Do you see that consistently when this issue reproduces for you?

[ruffson]

Is that log file from the same session as your latest recording? The timestamps in the log seem to end many minutes before the video.

I'm sorry I am not sure anymore if it was that occasion or another. I just wanted to demonstrate the behaviour, maybe the swallowing up of the cursor could be an indication where things break. Maybe this is more a problem with the window server and would not be a problem on Wayland?

Towards the bottom of the file:

 2021-05-23T16:14:04.707Z DEBUG mux                                 > removing pane 0
 2021-05-23T16:14:04.707Z DEBUG mux                                 > killing pane 0
 2021-05-23T16:14:04.707Z DEBUG mux::localpane                      > killing process in pane 0, state is Dead
 2021-05-23T16:14:04.707Z TRACE wezterm_gui::frontend               > Mux is now empty, terminate gui

it looks like wezterm thought that everything was done; it would typically terminate and close its windows at that point.

Do you see that consistently when this issue reproduces for you?

I will try to debug some more and tail -f it to check these things tomorrow. Although that log file was only generated when I started killing the processes.

[ruffson]

Ok so I reproduced it again this morning but it took me a bit and I paused in between which explains the time stamps in the log. The time where my tmux time stopped was 09:17:18.`

But the last entry in my log is from 6 am, probably not taking into account my time zone. I did not start at 6 am and I am in UTC +2.

Over the course of my morning I tried reproducing the issue, opened wezterms, opened some files in neovim, closed them etc. After that did not reproduce the problem, I left one of the terminals open. When I came back, I opened another window, tested again and could reproduce the issue. However I don't know if this is even reflected in the log at all (keep in mind I exited wezterm many times because closing one window is what triggers the hang in another open window).

wezterm_blocked.zip

I will stop using wezterm now unfortunately since I do everything in my terminal and this is a deal breaker but if you need me to test anything, please let me know!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.