Closed elpupi closed 2 years ago
Hehe I see you're using my multi-file config (with a few tweaks) :)
However I don't think all the config is necessary to reproduce the problem, can you try with no config? (with: wezterm -n
) or with a more minimal config? (to configure the font only maybe? since it might be a problem with font loading) (with: wezterm --config-file ./minimal-config.lua
)
The idea is to find the minimal config necessary to reproduce the problem, and help find the root issue.
I'm a bit preoccupied with moving house at the moment, so haven't had time to really dig in. If you could minimize the amount of configuration necessary to trigger the issue, that would help!
My first thought is that reloading the config is causing the font directory to be rescanned to search for a font with appropriate fallback glyphs; if you have a lot of fonts in there then it may take some time for the codepoint coverage to be evaluated. While a proper codepoint->glyph remains unresolved, wezterm substitutes a glyph from https://github.com/unicode-org/last-resort-font
If you start wezterm like this: WEZTERM_LOG=wezterm_font=trace,info wezterm
, stderr should show a lot of diagnostics about font loading, including statistics about computing coverage.
If your fonts are resolvable via fontconfig, then you may wish to remove the cfg.font_dirs
line from your config; wezterm will then use the available coverage information from fontconfig and won't need to build its own font database.
This issue has been automatically closed because there has been no response to the request for more information from the original author. With only the information that is currently in the issue, there isn't enough information to take further action. Please reach out if you have or find the answers we need so that we can investigate further.
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.
What Operating System(s) are you seeing this problem on?
Linux X11
WezTerm version
20211017-131416-24875004
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
Unicode utf-8 characters behaves strangely. Indeed, if I copy/paste "፨ style 🠒" in the wezterm, the output is is well displayed.
But weirdly, if I write few lines, using the stdin of the
cat
command for example, as so:I get various weird behaviors :cry: :disappointed:
Indeed, here, you can see that the lines are well displayed:
But if I reload the config (Ctrl-Shift-R or what you have in your config key binding), at one point, all the unicode chars get unrecognized. In this case, I had to paste 3 times the same text block.
I tried to create a minimal case but the behavior is apparently a bit unpredictable and I could not find a reproductible test case unfortunately.
Something even weirder is that from time to time, when I open a fresh wezterm, and I write the exact same command as previously that was working, the bug arises right away like with this
echo "፨ style 🠒"
Something I found out, is that if I type any unicode, but only one char, like "፨" for instance, the terminal outputs well the unicode chars again (that explains why you see this ፨ unicode char at the beginning of the first screenshots)
To Reproduce
As I mentioned it in the description, the behavior is a bit chaotic and not really reproducible. Each time, the bug arises but at a different moment. Here I will describe one test case that triggered the bug for me.
cat
, paste the following text፨ bg 🠒 [30;100mblack[0m ፨ style 🠒 bold ፨ bg 🠒 [31mred[0m ፨ style 🠒 bold
፨ bg 🠒 [32mgreen[0m ፨ style 🠒 bold ፨ bg 🠒 [33morange[0m ፨ style 🠒 bold
Expected Behavior
Unciode utf-8 characters should be well displayed and consistent.
Logs
2021-10-18T20:58:02.538Z INFO wezterm_gui::termwindow > OpenGL initialized! Mesa Intel(R) HD Graphics 620 (KBL GT2) 4.6 (Compatibility Profile) Mesa 21.0.3 is_context_loss_possible=false wezterm version: 20210814-124438-54e29167
Anything else?
No response