Wrapping long words eats up one character

[lapo-luchini]

% seq -s '' 100 199 | moar -wrap
  1 10010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213
    13413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616
    168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199
---

First line ends with "130 131 132 13[3]" second line starts with "134 135".

Also with different terminal width, still skipping last char on each line:

  1 1001011021031041051061071081091101111121131141151161171181191     0121122123124125126127128129130131132133134135136137138139140     4114214314414514614714814915015115215315415515615715815916016     1621631641651661671681691701711721731741751761771781791801811     2183184185186187188189190191192193194195196197198199
---

[walles]

I failed to repro this with moar v1.27.2 and iTerm2 3.5.5 (see below).

1. What does moar --version say?
2. What terminal program are you using? Does it repro if you try some other terminal?

[lapo-luchini]

I was using v1.27.0 but upgrading to .2 doesn't solve it. I'm using Windows Terminal, which is usually a good terminal (at least, I never had problems with tmux and mosh), but only now I noticed that the rightmost three columns (and last line) are completely black. This is with seq -s '-' 10 99 | moar -wrap (which is more readable): opening it inside tmux solves the problem while still having two black columns… I guess those are the culprit:

[lapo-luchini]

Ok, no, the blank columns/line seems to be because of HiDPI scaling, but the "missing letters column" (which goes away inside tmux) is I guess a separate issue. 🤔

[walles]

To rule out Windows specific issues in moar, would it be possible for you to try this with some other terminal app on Windows?

That would tell us whether this is:

1. moar doing something strange on WIndows
2. Windows Terminal doing something strange with moar's printouts

I have tried this (on macOS) and it works in:

• iTerm2
• macOS Terminal
• Hyper
• KiTTY
• WezTerm

Unfortunately Windows Terminal requires Windows, and since I'm on macOS that makes this tricky for me to troubleshoot.

[lapo-luchini]

I don't have other terminals installed (since Windows Terminal is usually pretty excellent, this one might be the first bug I encounter) but I tried using portable MobaXTerm and it works fine:

Using Windows Terminal I got the same exact bug (last column not showing) in both WSL Ubuntu and Windows native version, both using moar v1.27.2.

[lapo-luchini]

It also happens to me inside the terminal embedded in Microsoft VS Code. Which is available on Linux/FreeBSD and maybe macOS (?).

[lapo-luchini]

I tried getting terminal size as suggested here and I got the same width in both tmux or raw Windows Terminal.

Raw Windows Terminal:

% print "\033[9999;9999H\033[6n"
^[[50;106R

Inside tmux:

% print "\033[9999;9999H\033[6n"
^[[49;106R

(the difference is only vertical due to the status line)

[walles]

Seems like VSCode on Windows uses "ConPTY", which is the same thing used by the Windows Terminal IIUC: https://code.visualstudio.com/docs/terminal/advanced#_windows-and-conpty

That's why those are giving the same results.

So AFAICT this is still specific to the Windows Terminal...

Have you tried reporting this at https://github.com/microsoft/terminal?

Note that this could very well be moar doing something wrong, but since I'm not on Windows and this seems Windows (ConPTY) specific I don't know how I would go about troubleshooting this.

[lapo-luchini]

I will report there. 👍🏼 In meantime I tried to reproduce using VSCode on Linux… no bug there. So yes it seems to be Windows-specific.

[walles]

I believe this is related to how to write the last character of a screen line. If this was moar getting the size wrong, the wrap would be early rather than missing a character.

Also, since tmux manages to write there, it is possible, I just need to know how.

If you have a Go setup and want to experiment, the below function might be a good place to start.

Maybe it should be just \n at line ends? Maybe we should skip \r\n entirely if the line is as wide as the screen?

https://github.com/walles/moar/blob/d5f1cbd43d83c9e40347f6ef95665dbd72a65ac0/twin/screen.go#L747-L778

[lapo-luchini]

If you have a Go setup and want to experiment, the below function might be a good place to start.

I will gladly try. (I know very little Go, but enough to try)

[lapo-luchini]

(I did try a bit, no good result so far.)

[lapo-luchini]

I also tried conhost (the "old" Windows terminal)… which produces an "opposite" but similar result… 🤔

[walles]

This should now be fixed in just-released v1.27.3.

If you could try it out and report back @lapo-luchini that would be super!

[lapo-luchini]

Wow, I read the other issue and… what an informative ride! 💙

[walles]

Thanks for driving this to its conclusion @lapo-luchini!