Skip to content

Conversation

@ad08fee3
Copy link
Contributor

@ad08fee3 ad08fee3 commented Nov 27, 2025

Adding new package: emoji-picker 🙂

The included .yml file 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!

@ad08fee3 ad08fee3 changed the title Add emoji picker Adding new package: emoji-picker Nov 27, 2025
@ad08fee3 ad08fee3 marked this pull request as ready for review November 27, 2025 01:46
@smeech
Copy link
Collaborator

smeech commented Dec 11, 2025

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 :em for my email addresses.

A single choice form from a trigger. No script/shell or potentially malicious code.

I'll go ahead and merge.

@smeech smeech merged commit 4335ae3 into espanso:main Dec 11, 2025
1 check passed
@smeech smeech requested a review from Copilot December 11, 2025 12:14
Copy link
Contributor

Copilot AI left a 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.

Copy link

Copilot AI Dec 11, 2025

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."

Suggested change
**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.

Copilot uses AI. Check for mistakes.
Copy link
Collaborator

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

Copy link
Contributor Author

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.

Copy link
Collaborator

@smeech smeech Dec 14, 2025

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!

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 main branch (ie. PR merge), the publish-packages workflow is run
  • The last job updates the current_hub_sha.txt file in the hub-frontend, committing and pushing to main
  • 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

Copy link
Collaborator

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @smeech, I finally got around to doing this: #209

Thanks!


## 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.
Copy link

Copilot AI Dec 11, 2025

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.

Suggested change
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.

Copilot uses AI. Check for mistakes.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree.

@smeech
Copy link
Collaborator

smeech commented Dec 11, 2025

Feel free to ignore the Co-Pilot suggestions — I just wanted to see if its review was useful.

@ad08fee3
Copy link
Contributor Author

New PR: #206

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants