^ symbol is rendered as ◦ on OSX

[geekscrapy]

Small description
Whilst using the carat symbol ^ in regex, it is now rendered incorrectly as ◦ (a unfilled bullet). Copying the ◦ via syscopy-cell actually copies it as a ^ so I believe it is just the rendering (maybe #758?)

Expected result
^ to be rendered

Actual result with screenshot

The selected column was created with ='^', but as you can see it renders the contents as ◦.

Additional context
vd commit: 911f15e

[geekscrapy]

@ajkerrigan maybe you could test this as well if you have a second?

I've tried this in iTerm and the in house OSX terminal.

OSX version: 10.15.7

[saulpw]

@geekscrapy can you syscopy-cell on that and then pbpaste | hexdump -C and paste the output here? I am wondering if it's not MacOS but your particular localization/keyboard that's generating something other than the ASCII ^.

[geekscrapy]

00000000  5e 0a                                             |^.|
00000002

So its the correct code. The only thing that this happens with is vd, any other app is fine... Also, this has only just started since I updated to the latest commit today. Unsure how to check what version I was on previously.

Output from locale

LANG=""
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"

[geekscrapy]

Wait a second, is there something funny going on with the unicode parsing? I just googled the unfilled bullet symbol:

It has 5e in the code

[saulpw]

Ah, I see it myself when options.visibility is set, so it's not just you. Thanks for the bug, I'll look into it now!

[geekscrapy]

Nice! Yes I set my options.visibility to 0 (default) and it looks correct!

FWIW I have it at 100, for debugging/deving

[geekscrapy]

Not sure if this should work but it might be useful info for debugging:

echo -n '00000000: 25e6'| xxd -r | vd results in an error (which means vd doesn't open): UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe6 in position 0: unexpected end of data

But this opens fine, just the carat is still the wrong symbol:

echo -n '00000000: 5e'| xxd -r | vd

[ajkerrigan]

@ajkerrigan maybe you could test this as well if you have a second?

I've tried this in iTerm and the in house OSX terminal.

OSX version: 10.15.7

I didn't see this issue, but you've found a lot more context since you asked this!

[saulpw]

Thanks, @geekscrapy, the fix will be in shortly.