Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fitzpatrick emoji modifiers are treated as distinct emoji for width calculations #8275

Closed
lilyball opened this issue Sep 7, 2021 · 4 comments
Labels
bug Something that's not working as intended
Milestone

Comments

@lilyball
Copy link
Contributor

lilyball commented Sep 7, 2021

Latest fish master (3.3.1-288-g139b74d8e)

Fish thinks that emoji modified by the fitzpatrick emoji modifiers are in fact multiple emoji:

> string length -V \U0001F44D # 馃憤
2
> string length -V \U0001F44D\U0001F3FB # 馃憤馃徎
4

(U+1F3FB is EMOJI MODIFIER FITZPATRICK TYPE-1-2)

Meanwhile macOS Terminal.app handles the modifiers correctly when they follow emoji that support them.

I'm not sure what the correct solution for fish here is. The "correct" behavior is to bake in the full knowledge of what emoji support the fitzpatrick modifiers. I don't actually know whether this is something defined by unicode or is implementation-defined, though even if it is fully defined by unicode, that doesn't necessarily guarantee the implementations support it.

A simpler solution that would likely work in all common cases is to simply assume that the fitzpatrick modifier has width zero if it follows another emoji. Under normal usage it will only follow emoji that support it, and when displayed independently it won't be following an emoji. Having such a modifier follow an emoji where the combination is not supported either means someone is being deliberately silly, or it means the terminal emulator/OS is missing support for a combination that is supported elsewhere. Either way, assuming a width of zero is likely to be a much better experience in most cases than treating it like any other emoji. In particular, I should be able to put this in my prompt without causing my input position to be shifted unexpectedly.

@faho
Copy link
Member

faho commented Sep 7, 2021

This is annoying to fix, because we use "wcwidth" (meaning the width of a single codepoint) in a bunch of places. That basically can't work with these things - for e.g. korean hangul, I hacked it so the middle and end bits have a width of 0, so if they show up composed it works out. We'd need to switch to wcswidth and pass a full string, so the context isn't lost.

@faho faho added the bug Something that's not working as intended label Sep 7, 2021
@faho faho added this to the fish-future milestone Sep 7, 2021
@lilyball
Copy link
Contributor Author

lilyball commented Sep 7, 2021

This is why my immediate proposal is to just treat the Fitzpatrick modifiers as having a width of 0, in the expectation that they鈥檙e most likely following an emoji that supports it, and in the hope that the terminal emulator/OS does. I do not have any easy way to test Linux terminal emulators for this so I don鈥檛 know how safe an assumption it is that the terminal handles it; I hope it鈥檚 commonly supported though.

@faho
Copy link
Member

faho commented Sep 7, 2021

Yeah, that should work.

@ridiculousfish
Copy link
Member

I went ahead and hardcoded this single range instead of modifying widecharwidth. Thanks for filing!

@zanchey zanchey modified the milestones: fish-future, fish 3.4.0 Sep 12, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something that's not working as intended
Projects
None yet
Development

No branches or pull requests

4 participants