-
Notifications
You must be signed in to change notification settings - Fork 180
Adding new package: emoji-picker #204
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Having tried it, I really like this submission, as I can never remember precise emoji names! I'll need to change the trigger, as I already use A single I'll go ahead and merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR adds a new emoji-picker package to the Espanso package repository. The package provides a choice-based picker interface for inserting emojis based on search keywords, using Unicode Emoji data (version 16.0).
Key changes:
- Adds a new package with a single trigger (
:em) that opens a searchable picker containing all emojis with keyword-based labels - Uses Unicode Emoji 16.0 data from muan/unicode-emoji-json and keyword library from muan/emojilib
- Provides comprehensive documentation explaining usage, customization options, and differences from other emoji packages
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| packages/emoji-picker/16.0.0/_manifest.yml | Defines package metadata including author, description, version (16.0.0), and homepage reference |
| packages/emoji-picker/16.0.0/README.md | Provides comprehensive documentation covering rationale, usage instructions, and customization options |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # Emoji Picker | ||
|
|
||
| This is a package created for [Espanso](https://espanso.org/) called `emoji-picker` that provides a picker to select an emoji based on your input. | ||
|
|
Copilot
AI
Dec 11, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While the package version is 16.0.0, there's no mention in the README about what this version number represents. If it refers to the Unicode Emoji version (16.0), this should be explicitly documented to avoid confusion. Consider adding a note explaining the versioning scheme, such as: "This package version follows the Unicode Emoji version it supports."
| **Versioning Note:** This package version (16.0.0) follows the [Unicode Emoji version 16.0](https://unicode.org/emoji/charts-16.0/emoji-released.html) that it supports. Future updates will track new Unicode Emoji releases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The versioning would normally relate to the package itself, with incremental updates as required. I'm not sure why this one starts at 16.0.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted the version of the package to match the Unicode standard, yeah. So further changes would be 16.1.0, 16.2.0, etc.
But when it bumps up to Unicode 17 then it'd be 17.0.0.
But in hindsight maybe I should have made it be 1.16.0, 1.16.1, etc, and then up to 1.17.0? Then at one point it could be bumped up to 2.17 if there's some breaking change.
I don't know what'd be best. I thought I was being clever by making the version match unicode, but I probably should have done 1.16.0 instead. Oh well. Likely too late now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted the version of the package to match the Unicode standard, yeah. So further changes would be 16.1.0, 16.2.0, etc. But when it bumps up to Unicode 17 then it'd be 17.0.0.
But in hindsight maybe I should have made it be 1.16.0, 1.16.1, etc, and then up to 1.17.0? Then at one point it could be bumped up to 2.17 if there's some breaking change.
I don't know what'd be best. I thought I was being clever by making the version match unicode, but I probably should have done 1.16.0 instead. Oh well. Likely too late now.
That would have been good. I agree, it may be too late. My experience of trying to revert PRs in the repo is that the changes aren't picked up by the hub-frontend. We could try it, however. Deepwiki suggests we could amend 16.0.0 to 1.16.0, and then publish a new release, say 1.16.1, to trigger re-indexing.
The only person who would know how to is @arabello - I'll see if he can comment.
Co-pilot can be useful, evidently! I should have run it before merging!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My experience of trying to revert PRs in the repo is that the changes aren't picked up by the hub-frontend.
That's weird. The hub-frontend update workflow is as follows:
- When something is pushed to the hub
mainbranch (ie. PR merge), the publish-packages workflow is run - The last job updates the
current_hub_sha.txtfile in the hub-frontend, committing and pushing tomain - The hub-frontend deploy workflow is triggered and a new build begins
- The build fetches the last index JSON file from the main hub releases (which was updated in the first step).
So, the hub-frontend as no logic: the index JSON file is fetched on every build. If the PR reverts the changes and in the new index file the old version is replaces, the hub-frontend should see it. If this does not happen, I think it is more related to the main hub GHA workflows.
Hope this helps
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. We'll give it a go.
@ad08fee3, would you like to submit a PR changing the folder to 1.16.0 for all the files (and the version: value in _manifest.yml to match), and I'll merge it and see what happens?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
|
||
| ## Customization: | ||
|
|
||
| Being a simple text file on your PC, you are able to tweak the suggestions however you choose. Just know that any of the following suggestions may be overwritten if you update the extension! So maybe make a copy of the `package.yml` file and make your changes there instead. |
Copilot
AI
Dec 11, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The term "extension" is used here, but the correct terminology in the Espanso ecosystem is "package". This should be changed to "if you update the package" to maintain consistency with Espanso's naming conventions.
| Being a simple text file on your PC, you are able to tweak the suggestions however you choose. Just know that any of the following suggestions may be overwritten if you update the extension! So maybe make a copy of the `package.yml` file and make your changes there instead. | |
| Being a simple text file on your PC, you are able to tweak the suggestions however you choose. Just know that any of the following suggestions may be overwritten if you update the package! So maybe make a copy of the `package.yml` file and make your changes there instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree.
|
Feel free to ignore the Co-Pilot suggestions — I just wanted to see if its review was useful. |
|
New PR: #206 |
Adding new package:
emoji-picker🙂The included
.ymlfile is a single choice-trigger, and no other logic. However I did use a script to generate this file, which is visible over at https://github.com/ad08fee3/espanso-emoji-picker.This behaves differently than the other emoji Espanso packages, as I outline in the readme.
Thanks!