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.
Latest fish master (3.3.1-288-g139b74d8e)
Fish thinks that emoji modified by the fitzpatrick emoji modifiers are in fact multiple emoji:
(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.