Random black boxes (or pixels [or characters]) at the end of the name.

[The-Sound]

Sorry for opening an issue for something this silly, but I'm curious why of all my torrents (almost 4k) 2 random black characters/boxes/pixeles appear at at the end of the name:

Apparently, if I use bash, it's like they're eating up a character:

When I use ls -lah on their respective directories, their name appear normal:

As far as I've experienced, it doesn't affect the experience at all, so you can assign the lowest priority to the issue, is just that I don't have any other way to report this kind of thing and I was curious.

Thank you very much for the client, years after still goes strong!

[rndusr]

If it were just a few, my guess would be it's some kind of character encoding issue. I assume at least some of the torrent names only contain ASCII characters? Do you have the same issue with something like the Arch torrent? https://archlinux.org/download/ Which terminal emulator are you using? Can you try different ones?

[The-Sound]

I think they have a weird dash that I'm gonna try to paste here: – I don't know if it is gonna preserve the characteristics.
Anyhow, the rest of the files when listed with stig list name=~– don't have this issue, weirdly enough:

I know that preserving the names for privacy kinda goes against the spirit of reporting a glitch in the names, but I also noted that when stig prints the list it doesn't use the same dash as using ls because is not blurry:
So in that part I guess we're covered.

And nope, it doesn't happen with the archlinux torrent:

I'm using urxvt as a terminal emulator.
I've installed xterm for a quick test and has the same results, even if not blurred when using ls:

It also shows the black boxes:

PS: Following this random ascii lookup webpage it says the character is the next one:

[rndusr]

I tried with a torrent named "foo – bar" (where the "-" is "U+2013 EN DASH") and that looked fine. There could also be other characters like https://en.wikipedia.org/wiki/Zero-width_space in there. Can you create an example torrent that you can share? I appreciate that you are trying to help, but I think we're past the point where screenshots are helpful. You can create an example torrent like this: $ dd if=/dev/random of=random_data bs=1kB count=1 $ torf random_data --name 'Weird Torrent Name Goes Here' -o example.torrent https://github.com/rndusr/torf-cli/

[The-Sound]

I was trying to do the same test with mktorrent, when I realized that copying and pasting the "weird dash" changes the character itself. Following the breadcrumbs I ended up dumping it with cat on a textfile and I think I've found the culprit:

They appear to be normal or common dashes, but as far as I could understand, vi calls <200e>: Left-to-right character.
So my guess is that terminal emulators can't show the. . .Character? Encoding? Of that properly, and that translates into stig. Because the terminal emulators are "eating" up a character into the name and that's why they're misaligned or "blurry".

What do you think? I know this means 99% this isn't a stig issue but still I would love to hear your thoughts.

[rndusr]

No, that's definitely a bug in stig and I can reproduce the issue now. Thank you for your help! Do you have any issues in the interactive TUI when you run just `stig` or are we just talking about the CLI (`stig ls`)?

[The-Sound]

Beside the black boxes inside the TUI or the stig ls I didn't notice anything more.

Repasting earlier examples:

[rndusr]

Right, sorry for not paying attention. I think I understand what's happening. I'm not quite sure how to fix it, though.

[The-Sound]

Not a single worry! Thank you very much for keeping the project up and for being open with this kind of issues :D

[rndusr]

I'm not doing much. @rsekman is doing all the actual work and I mostly just nod and say thanks. But maybe I can fix this one by myself.

[rsekman]

I have also seen this happen, but I couldn't figure out a pattern to when it would happen. I kind of assumed it was in urwid or the terminal. U+200E is a Unicode codepoint that indicates what follows is left-to-right text, like English. There's a dual U+200F that indicates what follows is right-to-left text, like Arabic. Neither actually causes anything to be displayed on its own. Determining the length of a Unicode string is really tricky because many codepoints are like that, and others can combine. E.g. flag emoji are actually two special Regional Indicator Symbol Letters that are rendered as a country's flag if they form its ISO 639 country code (like JP for Japan). So yeah it's really easy to end up with these rendering bugs if you try to figure out how wide a Unicode string containing some of these special characters is.

[rndusr]

Thank you for the explanation. There's also the issue of east asian characters, which can be multiple ASCII characters wide. But they seem to work fine. Bidirectional characters seems to be more relevant to this issue: https://www.unicode.org/reports/tr9/#Introduction Python itself doesn't handle bidirectional (or bidi) characters in any way. They are just normal characters. >> 'foo\u200ebar' 'foo\u200ebar' The builtin unicodedata package (https://docs.python.org/3/library/unicodedata.html) doesn't help either. https://pypi.org/project/graphemeu/ is a package which sounds like it's exactly what we need, but it counts the LEFT-TO-RIGHT MARK as a normal character: >> grapheme.length('foo\u200ebar') 7 https://pypi.org/project/python-bidi/ doesn't help either. >> bidi.get_display('foo\u200ebar') 'foo\u200ebar' But https://pypi.org/project/wcwidth/ seems to do the trick. >> wcwidth.wcswidth('foo\u200ebar') 6 I committed a fix for the CLI, but I'm currently lost in the TUI code.

[rndusr]

I think I fixed this in the TUI as well. See my latest commit.

At least for torrent names. I think this should only be an issue when displaying torrent names
because they are also function as progress bars, but I'm not completely sure.

I'll make a new release in the next few days if nobody stops me.