cursor is being incorrectly placed when using tmux

[John Weachock]

I just started using tmux on my ARM Samsung Chromebook and I've started getting this weird issue where the cursor is slightly offset to the left in the rightmost panes. I'm not quite sure what the source of this bug is, but I figured I would ask here to see if anyone has any ideas.

I've attached four screenshots showing the cursor offset getting worse as I move right through the panes. In each picture the cursor is at the very start of my shell prompt and none of them contain any whitespace after it.

I'm using the ProggyCleanTTSZ at 16pt, Secure Shell 0.8.15, bash+tmux, and a ARM Samsung Chromebook on beta channel:

Version 25.0.1364.87 beta

Platform 3428.149.2 (Official Build) beta-channel daisy

Firmware Google_Snow.2695.114.0

Thanks in advance for any help! Let me know if any more info is needed.

[Robert Ginda]

Do you know what character if any is being used for the vertical bar?  If it's using a glyph that doesn't exist in your font then it's could end up rendered as a (gray on gray?) square of the wrong size.

Alternately, this could be a new regression in Secure Shell.  I changed the character measuring code recently to account for high-dpi displays like the Pixel and Retina Macbooks. I think that may have introduced or uncovered a rounding error that appears when you have a small font/wide window.

How many columns are in that window?

Can you try without tmux, but with the same number of columns?  See if the cursor gets progressively worse as it moves across the screen.

Rob.

[John Weachock]

I believe it's just a regular vertical bar character like most terminal UI programs use; the gray-on-gray is an intentional configuration. I've attached a few more screenshots without the gray-on-gray option set. I also took a screenshot of the cursor moved all the way to the right but with tmux un-split, so I'm fairly certain it's an issue with the glyph / measuring code. I will test all of this on my desktop later today to see if the same issues appear.

Thanks again for your help and for creating such a great extension! 

[John Weachock]

I just tested the same problem on my desktop and got the same results. However, I also temporarily changed the font to "DejaVu Sans Mono" and it fixed the rendering issue (including some others that I'd just attributed to tmux being wonky), so it must be Proggy's fault. If Proggy is missing a glyph, why does my standard gnome-terminal render the vertical bars correctly? Is there any way to replicate that behavior in my hterm?

[Robert Ginda]

The screenshot with tmux unsplit shows the cursor in the correct position, right?

On Secure Shell on my Linux workstation with the default font I'm able to get past 1k columns without cursor troubles, even in tmux with 4 vertical splits.

On a high-dpi display (Chromebook Pixel) I start to see cursor positioning issues early on, but only if I set the font size to nearly-unreadle.  Are you on a high-dpi display, or just the builtin screen on the ARM Chromebook?

At this point my guess is that Proggy is missing the vertical bar character that tmux uses, and so the browser is finding it in a different font (with a different size).

Can you run alsamixer and see if it looks all screwey?

I've tried installing Proggy but I'm having trouble getting Chrome to see it.  What's the font-face called?  How'd you get it installed on your Chromebook, dev mode?

The reason this would trip up hterm but not gnome-terminal comes down to implementation.  hterm has to trust the browser to render each character at the same size.  The alternative is to render each character inside its own DOM node and explicitly set the size of that node.  While that would provide a more robust display, the huge increase in DOM nodes would slow things down and blow up the memory requirements.  Gnome-terminal is a native app and not subject to these constraints.

I'm not sure the best way to work around this.  The quick answer is "don't use proggy", but I imagine you won't like that.  This issue is likely to show up in other fonts too, so even if you're ok with this, it won't last.

From a quick read of the man page I don't see a tmux option to change the vertical bar character.  We could potentially test for the missing graphic characters and translate them to ASCII graphics.  It wouldn't be bulletproof, but would solve the main issue of "tmux screws up the cursor position" at least.

Rob.

[John Weachock]

The screenshot with tmux unsplit shows the cursor in the correct position, right?

Correct.

On Secure Shell on my Linux workstation with the default font I'm able to get past 1k columns without cursor troubles, even in tmux with 4 vertical splits.

Everything worked for me as well on both CrOS and Ubuntu when using the default font. 

On a high-dpi display (Chromebook Pixel) I start to see cursor positioning issues early on, but only if I set the font size to nearly-unreadle.  Are you on a high-dpi display, or just the builtin screen on the ARM Chromebook?

Built in screen on the Chromebook. I can't test it on a high-dpi display, unfortunately. 

 

At this point my guess is that Proggy is missing the vertical bar character that tmux uses, and so the browser is finding it in a different font (with a different size).

Seems reasonable.

 

Can you run alsamixer and see if it looks all screwey?

Yep; looks horrible with Proggy. I've attached a screenshot of alsamixer and another screenshot of a second weird tmux issue. 

I've tried installing Proggy but I'm having trouble getting Chrome to see it.  What's the font-face called?  How'd you get it installed on your Chromebook, dev mode?

Yep, dev mode. Something along these lines:

crosh> shell

$ sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification

$ sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions X (whatever it told me to use)

$ sudo reboot

$ sudo cp ~/proggy.ttf /usr/share/fonts/

$ sudo reboot

It took me a lot of trial and error to get that working and it also gets reset everytime CrOS updates. Perhaps a future update of Secure Shell could allow for custom fonts? If not it's completely understandable, but I would very much appreciate it haha.

In my Secure Shell options I have the following: "ProggyCleanTTSZ","ProggyCleanSZ","ProggyClean","Proggy","DejaVu Sans Mono" at 16pt size. I wasn't quite sure what the font face was so I listed any possible cases. I've also attached my .ttf file.

The reason this would trip up hterm but not gnome-terminal comes down to implementation.  hterm has to trust the browser to render each character at the same size.  The alternative is to render each character inside its own DOM node and explicitly set the size of that node.  While that would provide a more robust display, the huge increase in DOM nodes would slow things down and blow up the memory requirements.  Gnome-terminal is a native app and not subject to these constraints.

Sounds reasonable.

 

I'm not sure the best way to work around this.  The quick answer is "don't use proggy", but I imagine you won't like that.  This issue is likely to show up in other fonts too, so even if you're ok with this, it won't last.

For the time being I'll just use the default font, although a fix or better workaround would be greatly appreciated. 

From a quick read of the man page I don't see a tmux option to change the vertical bar character.  We could potentially test for the missing graphic characters and translate them to ASCII graphics.  It wouldn't be bulletproof, but would solve the main issue of "tmux screws up the cursor position" at least.

I couldn't find an option either, unfortunately.

Again, thank you so much for your assistance. It means a lot! Keep up the good work.