mintty / wsltty

Mintty as a terminal for Bash on Ubuntu on Windows / WSL

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Inadvertent bidi rendering of some terminal UIs (lazygit)

Eryx5502 opened this issue · comments

Wsltty used to be my first choice for working with wsl and neovim, but it's been a while since I stopped using it because of some weird rendering when using some TUIs such as lazygit (see pics below). I couldn't figure out if is some configuration related issue, although I've tested with different fonts and tried out all configs on the configuration window but none seems to fix it. It looks like the line breaks are not rendered where they should.

Also, I don't know if it is related but the error happens for the first time when a glyph (pointed our with red arrows on the screenshots) should be rendered and, while Windows Term renders it correctly, Wsltty does not and then the line break errors start.

Please let me know if I need to provide any additional info.

With Wsltty:
imagen
imagen

With Windows Terminal:
imagen
imagen

commented

Please provide a reproducible test case.
You may try to produce a tty log with tee but that may not work well, so you may add an option -l C:\tmp\mintty-%d.log to your wsltty invocation shortcut, with an existing directory C:\tmp. The goal is to get a file that exhibits the issue when simply output with cat. Then upload that file here.

Here's the log: mintty-1020.log.

When cat the log file, the issue appears if I do it from wsltty but not if I do it from Windows Terminal, although for some reason it doesn't print the whole screen (see screenshots below).

Wsltty:
imagen

Windows Terminal:
imagen

commented

What's the size of your terminal?

It's 235x62

commented

The output contains right-to-left characters which cause the output direction to be changed and output reordered.
This can be disabled with mintty options -o Bidi=0 or --nobidi, or dynamically disabled if you configure the user-definable function toggle-bidi into your context menu.
About why your tool uses bidi characters ask them. If it's intended for layout, that's not a good idea and should be reported to them as a bug.

commented

The issue title also mentions tmux. Do you have a tmux example please, as a log as before?

Alright, that must be it since you're suggestion does stop the rendering issues.

About tmux, it was long ago when I noticed. I remember it used to happen when using the neovim plugin Telescope and tmux, but either I don't recall correctly or those are solved already by their teams. Anyhow, I'm not able to reproduce the error without Lazygit right now.

Just a question: I'm not so familiar with the field so I'm not sure what are the implications of using wsltty always with --nobidi. Is it not advisable or I can just add the option to my shortcut and forget about it?

Also, is it normal the glyphs are not rendering in wsltty but they do in Windows Terminal (both using the same font, Nerdfont version of Fira Code)?

commented

If you don't need to use bidi, just keep the option in.
Which glyphs do not render for you? שׂ (the Hebrew glyph) renders for me, font DejaVu Sans Mono.
Is that character part of your contents or does it come from lazygit?

Here there is a side by side comparison of wsltty (left) and windows terminal (right). Both have configured the same font and are attached to the same tmux session. On the WT (right) version there are icons on the branches section and also in the commits section, while on wsltty (left) there's either no icon or something different from the clear icons on the right.

imagen

commented

I see no mangled output here. If some glyphs do not display, it's most likely a font issue. Try DejaVu Sans Mono.
Also (see above), provide clear information what characters are not displayed so it can be analysed.

commented

Also, see my previous question. Are the Hebrew characters part of the contents you put into the panes or do they appear with empty panes already? In the latter case, I'd submit an issue to lazygit.

Sorry I'm not being clear. As said before, I don't really understand anything about terminal rendering or related stuff so it's kind of hard for me to explain.

I think lazygit uses some symbols (and probably some extra feature of some fonts such as FiraCode and/or some terminals) to render the git related icons on the screenshots from my last comment. In any case, I wouldn't say the issue is specifically related to lazygit: if I do echo "שׂ ﰖ שּׁ", the result rendered is diferent on wsltty and windows terminal, both using the same font FiraCode NerdFont:

  • Windows Terminal: imagen
  • Wsltty: imagen

Other fonts do behave differently on Windows Terminal also, which is what makes me think there's a font feature I'm not aware of having a role here (also, the rendered version by Windows Terminal does not look exactly as "שׂ ﰖ שּׁ").

commented

I'd still appreciate an answer to my previous question. If you start lazygit, I assume it still looks OK. Then you do something in one of the panes and the layout gets mangled, right? What do you run in there and is it part of lazygit or something else?

commented

Actually, sorry, you seem to have answered this just before, kind of, however leaving unclear some details.
Was echo "שׂ ﰖ שּׁ", part of your original test case? Why do you run it? What other program would output these characters?

Sorry for the unclear details. I'll try to clarify.

If you start lazygit, I assume it still looks OK. Then you do something in one of the panes and the layout gets mangled, right?

No, it is Lazygit who uses those glyphs mentioned on previous messages as part of its ui: it adds some of those as icons for each branch / commit. So the moment I open lazygit, on an existing git repository, the render gets mangled and only closing lazygit finishes the weird rendering.

Was echo "שׂ ﰖ שּׁ", part of your original test case? Why do you run it? What other program would output these characters?

It was not part of my original test case since. I didn't understand what was causing the issue until your replies. I do not run echo "שׂ ﰖ שּׁ" on my own, and I don't know any other program which would output these characters. However, the icons rendered on Windows Terminal with FiraCode are quite common and seems likely they appear on some (neo)vim pluggins using icons for instance.

Moreover, I believe the original issue is indeed caused by the rendering of this glyphs: I know nothing about these things, but when I paste the characters apparently it makes my writing start going from right to left.