- User Since
- May 25 2018, 1:49 AM (64 w, 4 d)
Jun 17 2018
Jun 16 2018
Thanks for the assist, @smf ! I appreciate it.
Next patch, emoji!
Thanks for the concrete feedback. I've uploaded a new diff. The (EXPERIMENTAL) tag has been added and I am now using hg export to generate the diff.
I don’t disagree with your premise, but the comments section of this patch are not really the right venue for this discussion.
Looks like your font is missing the dashed vertical line, and has an oddly small regular-circle glyph. I don't recognize the font at all so I can't really speak much more to that. Fortunately though...
For what it's worth, it works great on Linux, so no need to feel sad. That's my primary dev environment. If you aren't interested in actually testing the extension itself I'm not sure why you are posting here, but thank you for the feedback about type con issues with UTF8 on Windows. It was very elucidating.
Can you provide a screenshot of the actual Windows behavior?
Are you capable of running the extension?
Without more context I have no idea what you are trying to show. Windows is
certainly capable of rendering Unicode characters in the console. It is
also very possible to get ? characters if you're running a
non-Unicode-aware tool or if there are encoding mix-up issues. "type con"
and pasting in text from a text editor doesn't really prove anything one
way or the other. (What editor? What encoding did it think the data was?
How does "type con" handle Unicode text? etc.)
What are you trying to demonstrate here? I'm lost.
Jun 15 2018
I'm not worried about the date/time info. You can just add in my name.
Jun 14 2018
Side note: I'm unfamiliar with the lingo here, what's +0 on a feature? Indifference?
It all depends on your terminal font. It looks like the font you're using now has issues with U+2506 ┆ and is otherwise working as expected.
Jun 8 2018
Jun 3 2018
How do the new glyphs look in PuTTY with Deja Vu?
Is there anything else that you need me to look at in this patch?
May 31 2018
OK, I've fixed the latest nits in this diff, as well as changing the circle characters as discussed to:
I experimented some more in Linux and got some surprisingly different outcomes. Fallback rules definitely vary! Anyway, I think these glyphs are going to work the best across the widest variety of fonts. They are in the same character group so they should all be roughly the same size and shape, and in most monospace fonts they are large enough to be visually distinct.
I'm finding that on OS X, the following two glyphs get good results in almost every font, and great results in Menlo and DejaVu Sans Mono. I wish they popped a little more in Ubuntu Mono but they are still better than the current choices. I'll switch over to Linux now to verify there.
May 30 2018
A proper warning is now issued when the encoding is not UTF-8, or when East-Asian ambiguous characters will be rendered as wide characters.
The tests have been updated to check these warnings.
Yuya, I believe this should address everything we discussed. Let me know if you see a need for any further changes.
May 29 2018
yuya, I believe these patches should address all of your concerns except for encoding._wide. I am not sure what your expectation is for that. I don't think it would make sense to silently disable the extension if encoding._wide is set; IMO that would cause user confusion. If a user sees that the log lines are not lining up properly, that is easy to understand, diagnose and fix (change your Terminal font). If the extension just silently doesn't work, that is much harder to fix.
getprettygraphnode now honors HGPLAIN and UI encoding type.
May 28 2018
Corrected indenting issue. (In converting from 2-space to 4-space indents, I misaligned this block.)
Addressed warnings found by test-check-code.t.
Converted non-ASCII characters to `\xNN' form for Python 3 compatibility.
Converted sys.stdout.encoding to encoding.encoding.