Monaco font with tmux, vertical pane shows dashes rather than a continuous straight line

[ilnli]

On macOS Mojave v 10.14.1, when I use Monaco fonts, the vertical separation bar for tmux panes shows dashes rather than a continuous vertical line.

I'm using the following fonts:

font: normal: family: Monaco style: Regular bold: family: Monaco style: Bold italic: family: Monaco style: Italic size: 10.5

[chrisduerr]

Is the line height correct?

[ilnli]

Hi Chris,

Thanks for your reply, can you please tell me how to check line height?

[ilnli]

I'm using the following offset values in my config:

offset: x: 0 y: 0

glyph_offset: x: 0 y: 0

[chrisduerr]

There's no way to tell based on logs, since it depends on what your font reports. However when typing a letter like g, does it go below the height of the dashes?

Also is the distance between a g on one line and something big like a T on the next one significant?

My initial assumption would be that your font's just not providing glyphs that are high enough. But if that's not the case, chances are the cell height might not be correct.

[ilnli]

Yes, in the below screenshot, g seems to be below the height of the dashes, and the distance between g and T does look significant.

[ilnli]

[chrisduerr]

This really looks like your font is just providing symbols which aren't high enough.

[nixpulvis]

Would it help to see the same font inside another terminal, like Terminal.app or iTerm.app?

[ilnli]

The same font in iTerm or Terminal app don't suffer from this issue.

[ilnli]

I'm using the following colour scheme and the issue seems to be prominent in that colour scheme, some other colour schemes don't suffer from this problem:

https://github.com/aaron-williamson/base16-alacritty/blob/master/colors/base16-solarized-dark-256.yml

[chrisduerr]

@ilnli That sounds like your configuration file is breaking. Colorschemes change nothing about glyph size.

[Ciebiada]

I can confirm the exact same thing is happening to me. It works fine for Menlo font, but not for Monaco. It works in iTerm though. Maybe iTerm is doing something extra?

[domsch1988]

I too can confirm this happening. I'm using Inconsolata Nerd Font and a custom Nord Color Scheme

[chrisduerr]

It is entirely possible that iTerm might render these characters differently (which would kinda be incorrect, though they're commonly used for this purpose). Though it is also possible that these symbols don't exist in Menlo/Monaco/... and it's the fallback font which is causing issues. In that case it is possible that Alacritty isn't optimally using the fallback font.

I think the best choice would be testing this is another third party macOS terminal like kitty. If it can be confirmed to work there, there has to be something Alacritty is donig 'wrong', or at least a standard optimization Alacritty is lacking.

[ilnli]

I've tried to run kitty but it's not working on my system so can't confirm, however, on the native Terminal app, the issue doesn't happen and iTerm2 doesn't suffer from it either.

[cresny]

I can confirm, after using several different terminals this problem only occurs on alacritty, in my case using "Monaco for Powerline" font

[bkhl]

I get the same thing in Linux/X11, using several fonts, including Noto Sans Mono and Ubuntu Mono.

I don't see the problem with DejaVu Sans Mono, or the derivative Hack.

I don't think it's anything in my config, as I see the same thing with alacritty --config-file /dev/null, and my fonts.conf does nothing but map Noto Sans Mono to the alias monospace.

I don't see the same thing in e.g. Gnome Terminal.

[fernzi]

If I remember correctly, this doesn't happen in VTE-based terminals, like Gnome Terminal or Termite, because they render box drawing characters themselves instead of using the glyphs provided by the font.

For example, here VTE just draws a contiguous line, despite the line spacing, while Alacritty uses the individual characters from the font:

I imagine Terminal.app and iTerm do the same thing.

[chrisduerr]

@ferzapata That's a great point and it's definitely possible that's the case. In theory Alacritty could do the same, but I'm not sure if I'd want to go for that.

Maybe this could be tested in a different application? I know Firefox doesn't render custom characters, so it might be possible to set the font on some text there and check out how it's handling things. Though it's possible that the line height isn't 100% accurate there (but it should be possible to get it correct).

[fernzi]

@chrisduerr Firefox, and Chrome for that matter, just use the font as is, they don't expand to match the line-height or letter-spacing properties.

However, other terminals do handle those characters specially. Aside from the VTE ones (and presumably Terminal.app and ITerm), both Kitty and Konsole custom-draw box characters, and Konsole specifically even has a "Use line characters contained in font" option to disable it.

Personally, I'd prefer if Alacritty did as Konsole does, as it lets terminal apps look as intended regardless of the line/character spacing, while still allowing to opt out of it and use the font glyphs just-in-case.

[chrisduerr]

I guess I'd be fine with drawing them ourselves tbh. Especially since we do now have ways to draw filled rectangles easily built in for underline and strikeout already.

The only question would be thickness and for that the underline thickness should be a good metric to use. Strikeout isn't available on all platforms, so just using the same width as what the main font specifies for underline should be good.

[chrisduerr]

I'd also like to point out that this is slightly related to https://github.com/jwilm/alacritty/issues/118.

If we decide to go for drawing our own box drawing characters, one of the biggest drivers behind #118 would be gone. I don't want to merge these issues together however, because I think they're still fundamentally different.

Even with custom box rendering, I think there's still value behind properly rendering multiple characters above each other and if rendering characters above each other is fixed, there's still value in drawing custom box characters.

[cloudlena]

For me, the workaround described in the wiki resolves this issue and also some other ones.

Are there any plans for fixes that would make Alacritty work with tmux without this workaround? I'm using the tmux zprezto module to auto start tmux so I cannot easily set the -u option and my terminal always opens in tmux.

[chrisduerr]

@mastertinner There's probably a config option for it and ZSH_TMUX_FORCEUTF8=true might also work.

[kchibisov]

@mastertinner The problem is in your locale, tmux can't understand that your locale supports UTF-8, we have an issue #2566 to track this problem and I recommend you to read through the mentioned thread, to apply better workarounds rather than passing -u to tmux. One temporary workaround is adding LC_ALL: "en_US.UTF-8" (or whatever locale you are using) to env section in alacritty.yml.

[cloudlena]

Thanks for your replies, @chrisduerr and @kchibisov. I just noticed that, when I start tmux manually, it works fine (because my LC_ALL is already set to en_US.UTF-8). So the bug must be with zprezto. I'll create an issue there. Sorry for the troubles and for hijacking this issue.

[kchibisov]

@mastertinner There is one more option, you can add this line to .tmux.conf set-environment -g "LC_ALL" "en_US.UTF-8"

[chrisduerr]

Closing as duplicate of #957 and #118 (see https://github.com/alacritty/alacritty/issues/827#issuecomment-620822975).