[WIN] Font loading issue

[God-damnit-all]

wezterm 20191124-233250-cb9fd7d-110-g8950c6c
(not sure why the date is 20191124, this is supposed to be the nightly?)

I'm glad you told me about RUST_LOG=warn because apparently I wasn't paying attention before (and I haven't been having to use the terminal due to the holidays). When It had stopped throwing toml parseing errors I thought it was working. But I don't think it is. I'm using Fira Code from here to test with.

[[font.font]]
# The font family name.  The default is "Menlo" on macOS,
# "Consolas" on Windows and "monospace" on X11 based systems.
# "Fira Code" to enjoy ligatures without buying an expensive font!
font_system = "FontKitAndFreeType"
font_dir = ["fonts"]
family = "myfont"

Without the 'family' line it throws a parsing failure error. I also tried "myfont.ttf" in family, no luck.

The output:

ERROR wezterm::font::parser > Did not locate a font match for FontAttributes { family: "myfont", bold: false, italic: false }
 ERROR wezterm::font::parser > Did not locate a font match for FontAttributes { family: "Segoe UI", bold: false, italic: false }
 ERROR wezterm::font::parser > Did not locate a font match for FontAttributes { family: "Segoe UI Emoji", bold: false, italic: false }
 ERROR wezterm::font::parser > Did not locate a font match for FontAttributes { family: "Segoe UI Symbol", bold: false, italic: false }
 ERROR term::terminalstate   > unhandled TerminalMode 25

For user error auditing purposes, here's the output of tree /f /a:

|   wezterm.exe
|   wezterm.pdb
|   wezterm.toml
|
\---fonts
        myfont.ttf

and here's myfont.ttf showing Fira Code Regular:

[God-damnit-all]

Wait a second, no I didn't. For some reason the nightly's wizterm --version command just shows 20191124 even though it was compiled on 20191215?

[wez]

wezterm 20191124-233250-cb9fd7d-110-g8950c6c
(not sure why the date is 20191124, this is supposed to be the nightly?)

That's all produced by git; the important thing is the last bit because it corresponds to the actual git commit hash but with a g in front: 8950c6c

[[font.font]]
# The font family name.  The default is "Menlo" on macOS,
# "Consolas" on Windows and "monospace" on X11 based systems.
# "Fira Code" to enjoy ligatures without buying an expensive font!
font_system = "FontKitAndFreeType"
font_dir = ["fonts"]
family = "myfont"

I think there might be some toml weirdness going on. The font_system option was broken up into three new options in master; these are all supposed to go at the top level of the config file, rather than in a font.font section:

• font_locator - which tells us how to find the system fonts. I think you're using the new ConfigDirsOnly value for this. But otherwise I'd recommend omitting it.
• font_rasterizer - just leave this as the default
• font_shaper - just leave this as the default

font_dir should be named font_dirs and belongs at the top level also. Fixing that will show the "warning" level output that should show that your font contains "Fira Code".

So I think your config should look like this:

font_dirs = ["fonts"]

# Optional, but makes it very easy to spot a problem!
font_locator = "ConfigDirsOnly"

[[font.font]]
family = "Fira Code"

ERROR wezterm::font::parser > Did not locate a font match for FontAttributes { family: "Segoe UI", bold: false, italic: false }

I also saw these on my windows box; these come from some hard coded fallback logic and I think I need to finesse it a bit. You can safely ignore them!

[God-damnit-all]

Aha, I see. So I actually did have a working configuration before. The only reason I changed family to myfont was because I figured I should go off what the commit message for 1e9d357 said for troubleshooting purposes. I didn't realize font_system and font_dir were both deprecated.

(Sidenote: You're probably already aware, but font_dirs = ["."] works on Windows to specify the wezterm.exe directory.)

Any idea what ERROR term::terminalstate > unhandled TerminalMode 25 refers to?

[wez]

Any idea what ERROR term::terminalstate > unhandled TerminalMode 25 refers to?

Sounds like the DECTCEM sequence that controls whether the cursor is visible or not; https://www.xfree86.org/current/ctlseqs.html has a list of codes.

We don't currently do anything about this sequence, so we log it as unhandled.
I'll add this to #7

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