Line drawing artefacts in Tree on Windows, in Windows Terminal
#2548
Comments
|
Update: not just line drawing characters. Still only seeing this in Windows Terminal. This particular glitch only happened when the focus was on the same row. 
|
|
I've got the same problem on Windows as well. |
|
@willmcgugan Looking back to find this issue again and this very much looks to be the same thing we were looking at at my desk just now, with the key tester/recorder app under Windows (both Terminal and Hyper). The behaviour I recorded above, with the directory tree, displayed all the same symptoms and had the same feel in regards to the possible underlying cause (multibyte character at the end of a buffer sort of thing). |
|
Moving this into todo. I feel this is important enough that it go into the queue of things getting attention soon; even if it's to narrow down the cause. |
|
@davep This behaviour is a bit unpredictable, but from playing around with this I think I've discovered that weirdly this seems to go away when the padding setting in Windows Terminal is set to zero... |
|
Interesting. The working hypothesis was that it was a buffer size issue on our side (either in Textual or Python). Hadn't considered it would be a Windows Terminal issue. It'll be interesting to try and reproduce the issue in Tabby, Wez or Hyper, etc. What you say suggests it should not happen. |
|
I might be wrong as the behaviour is a bit unpredictable. But interestingly, it looks like the problem also goes away if you set the padding to the same size as the font. Edit: Nope, looks I can reproduce on Wezterm after minimising then maximizing the window, so this must just be pure coincidence, sorry.
|
|
No apologies needed. All useful stuff for eliminating the possible causes and influences. |
|
While messing around with resizing the Windows Terminal, I found you also can create other strange displays like below. The other screenshots show missing glyhs, whereas here it looks like the bottom corner of the border has been duplicated.
|
|
Trying to make a small tool that will hopefully allow me to get a stable reproduction of this issue and... so far so good. One thing I've found is that, given a particular terminal size (I've not tried other sizes yet, that's next), I can get corruption to appear at the exact same spot, every single time:
If I close the app down, run it up again, the corruption appears in the same place, starting around character 1504. The second location is always 3584. |
|
Different terminal sizes have the corruption at different locations, but always in the same location every time. There is a pattern. Likewise, if i make a fresh terminal the same size as the one above, I see the exact same pattern. |
|
🍿 |
|
Using the same test application, I've recreated the problem, with very similar results, using:
I did try rio too but, while I've managed to install it, I can't seem to get it running to the point that I get a prompt. I think it's fair to assume though that the issue will be evident there also. This would very much suggest that the problem is either within Textual itself, or something in the Windows build of Python. |
This is experimental. I think, ideally, we'll do this by finding an optimal buffer size and writing based on that, but for the moment let's just try line-by-line as that's easy. This will be used to test against the tool I've made that lets me recreate the issue documented in Textualize#2548; if this does the job we'll take this further.
|
Quick experiment with davep@357268e and it seems to be solving the issue. |
First we tested this by splitting the output by lines; that worked but it could be faster. So now we're going to take the problematic buffer size (32KiB), assume a reasonable worst case of every character heading out being 3 bytes in size, and chunking the output based on that. In other words, experiment for Textualize#2548 take two.
|
Seems to be down to python/cpython#82052 so fix is incoming which will chunk up the writes when on Windows. |
|
Don't forget to star the repository! Follow @textualizeio for Textual updates. |
|
Oof, nice work! 👏 |
|
To be clear: this was a known issue, and was what was suspected to start off with (see initial details), and this is applying a version of a workaround that's already in Rich. So I can't take credit for the fix, just perhaps for being double-sure that the problem was the problem. ;-) |
To start with I'm adding this as a tentative bug report, as I doubt it's really a
TreeorDirectoryTreeissue, but I have never seen it before and only noticed it while testing the work done on #2545; it's very likely going to require some attempts at isolation.Simply put, while playing with a sandbox application to soak-test the worker-updating of
DirectoryTreeon Windows, depending on terminal size, sometimes I'd see artefacts like this:Presumably the old "multibyte character got truncated" issue. Unsurprisingly it would then throw off the rest of the line it was on:
Here's the whole terminal, putting it in context (see the bottom row):
However... in this particular case, the issue would only show up if focus was within the first six director trees (the first two rows). If I tabbed focus into any of the final three it would fix itself:
As mentioned above, this did seem to change the way it worked depending on the size of the terminal, and the content; but I didn't really spend too much time trying to narrow that down as I was trying to concentrate on the thing I was in Windows to test.
I've not been able to recreate the issue on macOS.
Like I say: this is placed here for further investigation, and hopefully to take a bit of time to try and come up with a way to replicate the problem in as minimal an example as possible.
The text was updated successfully, but these errors were encountered: