tmux on Cygwin displays broken separators

[carlescufi]

Windows Terminal version

1.15.2875.0

Windows build number

10.0.22621.675

Other Software

Cygwin 3.3.6-1 tmux 3.2a

Steps to reproduce

1. Open a new tab with a Cygwin profile.
2. ssh into an Ubuntu virtual machine
3. Run tmux new -s mysession

Expected Behavior

Separator bars are displayed correctly

Actual Behavior

[lhecker]

Which font family and size are you using? Did you configure any font axes or features? It's likely that this issue won't reproduce in Windows Terminal Preview as it defaults to another text renderer (which unfortunately has its own set of issues I'm currently working on).

[carlescufi]

I am using CodeNewRoman NF from NERDFonts.: https://www.nerdfonts.com/font-downloads

[lhecker]

That font isn't monospace:

You have to use CodeNewRoman NFM instead. The .zip contains files that include "Mono" in the name, which can then be used with the NFM suffix (with M being short for Monospace).

[carlescufi]

That font isn't monospace:

You have to use CodeNewRoman NFM instead. The .zip contains files that include "Mono" in the name, which can then be used with the NFM suffix.

Although you are theoretically correct, in practice CodeNewRoman NF is monospace indeed, just tested this:

Anyway I switched to NFM and changed nothing, the separator is still broken. Let me know if you'd like me to try another font.

[carlescufi]

Actually, scratch that. You are right, my mistake. I got confused by the way mintty handles this, which I was using as a reference.

[carlescufi]

@lhecker first, thanks for correcting my mistake. Second, I wonder if you know why Windows Terminal shows the NF font differently than something like mintty, which shows it identical to NFM. Thanks in advance!

[lhecker]

From what I can tell, mintty places glyphs in a monospace grid no matter what font is used. Basically, it discards the font's "glyph advance" (the "width" of a glyph) to make them fit into the grid. Windows Terminal's renderer on the other hand uses the font information wherever possible. This is the code in mintty that's responsible for the behavior: https://github.com/mintty/mintty/blob/cbaa7665c82accc91a395414be121f2a435a6e03/src/wintext.c#L3108-L3118

I have a branch where I'm doing the exact same thing as mintty, but I unfortunately haven't completed that work yet. Once we merge that, Windows Terminal will work with any arbitrary font (include script fonts, like Segoe Script).

[carlescufi]

@lhecker thanks very much for the insight. I just checked and Terminal.app and it seems to behave just like mintty.

I have a branch where I'm doing the exact same thing as mintty

So this behavior is the future of Windows Terminal?

[lhecker]

Yeah I'd say so. However I don't intend to do it to make proportional/non-monospace fonts like CodeNewRoman NF work and I don't think that's why mintty/Terminal.app/... do it either. I believe this is more like a result of trying to make complex Unicode work better in terminals, because fallback fonts that contain such Unicode are usually never monospace. For instance a single emoji can mess up your layout in VS Code:

While this can be tolerated in a text editor, a terminal needs to be stricter in my opinion. And that's why I'm sure that this is the future of Windows Terminal as well. The strict monospace layout already works in the new "AtlasEngine" text renderer that you can try out in Windows Terminal Preview. But I'm now working on combining the benefits of the old and new text renderers to allow arbitrary overlapping fonts (like cursive script fonts) with strict monospace. I'm hoping to finish this new text renderer within this year.

[carlescufi]

@lhecker thank you again for the lengthy explanation.