[Feature] allow setting skin tone

[markstos]

If your search matches an emoji with skin tones, your results can be spammed with all the skin tone variations of one or two emojis rather than showing you 10 or more different emojis. The result you are looking for may be pushed off the first page by all the skin tone variations.

For example, if you search for red, there are 6 entries for "man with red hair", 6 entries for "woman with red hair" and 6 more for "person with red hair".

If a skin tone could be set on the CLI, there could be only 3 results instead of 18:

bemoji --skin-tone="medium"

• man: medium skin tone, red hair
• woman: medium skin tone, red hair
• person: medium skin tone, red hair

Or, perhaps even cleaner is not mention the skin tone at all when it's given on the CLI, so the results could be simply:

• man: red hair
• woman: red hair
• person: red hair

In this case "man: red hair" would actually show and select "man: medium skin tone, red hair" instead of the generic "man: red hair" emoji.

[marty-oehme]

This is an interesting idea, removing duplication while keeping choice.

As of right now I am not sure how to implement it while keeping universal support for character lists, however.
Currently, there are two lists of unicode symbols: emojis (some of which signal variation with :) and math symbols.
The user can add any space-separated list of symbols additionally.

We can not just shear off everything after a colon since it could be part of just natural text for additional symbol lists.

I am trying to think of a way something like this could be accomplished without coupling the picker too tightly to the single emoji list.

[markstos]

I looked at the Unicode file that bemoji is downloading and using. All the "skin tone" entries have 4 code points while the parent only has three:

1F469 200D 1F9B0                                       ; fully-qualified     # 👩‍🦰 E11.0 woman: red hair
1F469 1F3FB 200D 1F9B0                                 ; fully-qualified     # 👩🏻‍🦰 E11.0 woman: light skin tone, red hair
1F469 1F3FC 200D 1F9B0                                 ; fully-qualified     # 👩🏼‍🦰 E11.0 woman: medium-light skin tone, red hair
1F469 1F3FD 200D 1F9B0                                 ; fully-qualified     # 👩🏽‍🦰 E11.0 woman: medium skin tone, red hair
1F469 1F3FE 200D 1F9B0                                 ; fully-qualified     # 👩🏾‍🦰 E11.0 woman: medium-dark skin tone, red hair
1F469 1F3FF 200D 1F9B0                                 ; fully-qualified     # 👩🏿‍🦰 E11.0 woman: dark skin tone, red hair

It also looks like the text downloaded is only in English, so there's not I18N complication.

If we don't consider the challenges with math symbols, it seems that lines that match "skin tone" and don't match the --skin-tone flag could be filtered out.

[marty-oehme]

It's true that the downloaded text itself is English-only currently and I see what you are saying about the code points. The harder issue isn't necessarily translation related, but to the logic of showing/hiding grouped items.

Downloaders currently strip of the displayed initial code points and just keep the trailing emoji and description.
If anything, this means we have to take care of creating special categories for the 'four-point' emojis (e.g. the ones with skin tone) at list creation time,
that is when first running the program (in most cases).
Subsequently the picker simply displays all lines of all the lists it finds in the data directory, without applying any logic (currently).

To change this for displaying skin tones in a sub-menu, we would have to first filter the entries from being shown first time,
keep them in a specific cached location (in-memory may be possible) and then show only them (or, at least the ones applicable) second time round.

So, there are three changes necessary:

1. Define a specific control sequence the program recognizes as 'sub-group' for its list entries (e.g. ::: three colons or something which would be unlikely to naturally occur in entry descriptions).
2. Have the downloaders put any emoji that should be sub-grouped (i.e. skin tones) in the right syntax (e.g. 👩🏼‍🦰 woman ::: medium-light skin tone, red hair).
3. Have the picker recognize these sub-fields and hide all but 1 of their entries on picking, if one of the entries is picked have it display a second picker with other options of the same group.

It honestly seems an interesting feature which could enable more intricate selections in general (aside from emoji skin tone) but also seems like it would be a non-trivial change in the picker code which so far contains zero logic.

I'll have a think about it and may play around with it when I get some time, and invite anyone to also have a play to see if it could be implemented elegantly.

[markstos]

Here's an alternate implementation idea: Just run a filter and at download time and be done with it. The skin tone I pick is a default is unlikely to ever change.

Generic solution

Something like:

--dl-filter ~/.config/bemoji/medium-skin-tone.sh

The filter would accept input on STDIN and print to STDOUT.

Skin-tone-specific solution

But since filtering to a single skin tone might be the common use of a filter, perhaps there could be an option for just for that:

--skin-tone medium

The documentation would explain that the filter is applied at "download time" not at "run time", so to change the value, you need delete the download cache. Or the current skin tone could be cached in ~/.cache. If it's detected to be changed, then a fresh download is done so the filter can be re-applied.

Example filter

Here's a filter which accepts a skin tone as an argument and excludes the other skin tones which don't match:

#!/bin/sh
# Call with argument of light, medium-light, medium, medium-dark or dark. 
perl -pe "s/.*?(?<!$1) skin tone.*\n//"

Ex: filter-skin-tone.sh medium-light

Workaround

As a workaround, you can run the filter directly against your Emoji database. I did this now and it's working well. Here I embed the target skin tone in the perl code rather than use a wrapper script:

perl -pi -e "s/.*?(?<!medium-light) skin tone.*\n//" ~/.local/share/bemoji/emojis.txt

[marty-oehme]

This is actually a fairly clever idea, i am especially taken with the generic filter solution.

We could then supply a filter for skin tones by default, keeping it e.g. in the .local/share/bemoji directory and have bemoji look there if the supplied filter is not a file.
This would maybe give us a mix of best of both worlds (quick access to often used filtering and flexibility).

Will run with this idea a bit when I next have some time to devote!

[markstos]

I went ahead and filtered my emojis.txt file and I'm happy enough with the result.