You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
The text was updated successfully, but these errors were encountered: