Closed ssokolow closed 5 years ago
Thanks for the report!
I suspected that there might be more terminals emulators still in use that doesn't support emoji, but I cheated a bit by using #[cfg(not(target_os = "windows"))]
to get some results faster.
A better way could be to use something like https://crates.io/crates/console, possibly, haven't tested it.
the problem is that rxvt-unicode doesn't like U+FE0F (VARIATION SELECTOR-16)
It seems like rxvt-unicode doesn't support emoji? Hopefully the console create or some alternative on crates.io can provide emoji support detection at runtime.
It seems like rxvt-unicode doesn't support emoji? Hopefully the console create or some alternative on crates.io can provide emoji support detection at runtime.
It renders the U+2622 RADIOACTIVE SIGN
just fine (aside from the font involved being monochrome for it). It's just the U+FE0F VARIATION SELECTOR-16
it has trouble with.
We'll need to detect what level of emoji support is available then, or add a special case for rxvt-unicode since we know that it doesn't support the Emoji presentation of this specific symbol. I'm not sure if the text monochrome version is classified as an emoji or not:
http://www.unicode.org/reports/tr51/#Presentation_Style
--charset ascii
) flagEDIT: Or maybe flipping it around would be better, detecting specific terminal emulators that are known to support "Emoji presentation selector" is a better approach?
BTW, would you be interested in digging into this issue and providing a PR?
A tiny workaround for rxvt-unicode or a more general solution would be better than the current situation :)
Unfortunately, at the moment, I'm having trouble allocating time for my own projects which are in need of maintenance.
I totally understand ;) same thing here. If things change and you feel compelled to dig into this or any other issue/feature in cargo-geiger I will be delighted.
I'll add the missing pieces related to --charset ascii
to begin with, maybe I'll find some time later this week.
The --charset ascii
was fixed by #66
Would this be an acceptable workaround in your opinion? Or should there be two levels of fallback symbols, the lowest level of detail --charset ascii
and one level where the U+FE0F VARIATION SELECTOR-16
is absent?
I'd probably do two levels of fallback, but then I'm a perfectionist about my UIs so I'm not really the best person to get an opinion from on that point.
Hehe... and I was hoping that you were going to say "naah it's good enough" : )
I agree, two levels of fallback would be nice, let's keep this issue open.
I just did a re-test on the same version of cargo-geiger since I realized that the machine I was testing on before was a *buntu machine where the upgrade off the EOLed 14.04 LTS had been delayed but has since been upgraded.
Now that it's been upgraded, urxvt
looks fine, but UXTerm still would benefit from a middle option. It displays the line-drawing characters fine but doesn't seem to like emoji:
(Plus, it wouldn't suprise me if RHEL and SLES still have problematic urxvt versions.)
Thank you for the feedback. Having thought about this some more, I'm going to close this now since cargo geiger --charset ascii --color never
, since #66 and release 0.7.3, should provide an ok workaround. Please create a new issue if you think the second level of fallback is urgently needed.
I think that's reasonable. Supporting Unicode box-drawing characters but not emoji is a pretty niche situation.
On a brand new cargo-geiger install (
cargo install cargo-geiger
producing version 0.7.2), I get the following less-than-ideal output when running cargo-geiger under a stack of rxvt-unicode and GNU screen:--charset ascii
does change the tree-view line-drawing characters (which render just fine in the default UTF-8 mode), but doesn't change the more important icons.(I haven't checked your code but, when using the radioactive symbol emoji in your README for testing, the problem is that rxvt-unicode doesn't like
U+FE0F (VARIATION SELECTOR-16)
)