Alternative handling of recent characters

[stefanradziuk]

I've been enjoying using rofimoji and wanted to adjust it to my workflow.

The alt+num shortcuts for inserting recent chacters didn't feel very natural to me, so I made my own fork where recent characters show up as initial elements of the character list. This is somewhat similar to how rofi in run mode has the most frequently picked programs at the top.

Here's my prototype: https://github.com/stefanradziuk/rofimoji (currently overrides the default behaviour).

If this is a feature you would potentially be interested in merging into rofi (as non-default behaviour, available by passing an option)? If so, I would be happy to clean up my code and submit a PR.

[fdw]

Hey! First, sorry for the late answer... I seem to be quite busy at the moment 😐

But I'm always interested in ideas, so thanks for reaching out!
Your idea sounds quite intriguing, but I remember some questions/problems I had when I originally implemented the most recently used list:

• If I read your code right, then you have to filter all entries whether they are in the MRU list. That seems like it could be a potential performance problem. What do you think?
• This is also the way to find the descriptions for the MRU characters, right?
• What happens if you select more than one character, or if you selected a skin tone? Then the matching with descriptions won't work, would it?

[stefanradziuk]

• If I read your code right, then you have to filter all entries whether they are in the MRU list. That seems like it could be a potential performance problem. What do you think?

Currently the filtering can take up to characters-length * max-recent comparisons so you're right that there is potential for a performance hit with larger chacter sets or when setting a high value for max-recent (it does not necessarily have to be restricted to 10 when they are not being displayed on a bar).

One way to alleviate that would be making a set of recent characters (O(max-recent)) so that the filtering can be done in O(characters-length), which I think would be negligible compared to loading the characters from file.

Another way to do it would be to store all the entries in the desired order in rofimoji/recent, similar to how rofi's run mode caches entry frequency in runcache.

• This is also the way to find the descriptions for the MRU characters, right?
• What happens if you select more than one character, or if you selected a skin tone? Then the matching with descriptions won't work, would it?

The descriptions could be stored in rofimoji/recent in the same / similar csv format as they are originally stored, including for skin tone variants.

Handling multiple character entries is something I haven't thought of because up until now I thought they were being saved as separate recent entries. They could either be saved separately and displayed with descriptions or saved together and displayed without descriptions.

[fdw]

One way to alleviate that would be making a set of recent characters (O(max-recent)) so that the filtering can be done in O(characters-length), which I think would be negligible compared to loading the characters from file.

characters-length is the number of characters shown in rofimoji, right? I'm not very confident that that's not a problem (there's 1800 emojis), but there's also only one way to find out - trying it 😉

Another way to do it would be to store all the entries in the desired order in rofimoji/recent, similar to how rofi's run mode caches entry frequency in runcache.

I had also thought about this, but reading 1800 characters, sorting them and writing them again is quite surely not cheaper, I think.

They could either be saved separately and displayed with descriptions

Then you would have to call them individually again :/

saved together and displayed without descriptions

Which means you can't search for them, and it doesn't look as nice.

All in all, I think the bar isn't a bad implementation of the idea, but I'm open to others. Do you think you can update your branch to the latest main and make it configurable? If you open a PR with that, I'm more than interested 🙂

[stefanradziuk]

characters-length is the number of characters shown in rofimoji, right? I'm not very confident that that's not a problem (there's 1800 emojis), but there's also only one way to find out - trying it

I'm expecting iterating through 1800 lines loaded into memory to be much faster than loading 1800 lines from the filesystem (which happens every time rofimoji is ran if I'm reading the code correctly), so I don't think it would be noticeable. I might have a look at benchmarking that when I have some more time.

I agree that multi-character choices and skin tone options need some further consideration - I personally don't use those features very often so they didn't come to my mind at first.

All in all, I think the bar isn't a bad implementation of the idea, but I'm open to others. Do you think you can update your branch to the latest main and make it configurable? If you open a PR with that, I'm more than interested

I already made those changes a while ago but forgot to push them. I'll clean it up a bit and hopefully manage to open a PR later today/tomorrow.

[fdw]

Thank you 🙂

Also, no stress, you see how quick I am at the moment ;)

[fdw]

As also discussed in #78, I have now a branch frecency working that orders the characters by their usage. I think this is a nice, generic solution for this idea, as it only uses the base characters and thus avoids issues of description, skin tones etc.

Please check it out and report back! 🙂