Alfred Emoji: Search emojis by name or keyword

[Ryan McGeary]

Search for emoji and copy them to the clipboard ?.

Download v1.8.1 (2019-09-27)

 

Usage:

emoji [query]

• Press [return] (↵): Copy the symbol of the selected emoji (e.g. ?) to your clipboard.
• Press [alt]+[return] (⌥↵): Copy the code of the selected emoji (e.g. `:rofl:`) to your clipboard.
• Press [cmd]+[return] (⌘↵): Paste the code of the selected emoji (e.g. ?) to your frontmost application.

 

Automatic Updates:

 

This workflow will automatically check for updates at most once per day. If a new release is found, it automatically downloads and installs the latest version of the workflow. All downloads come directly from official GitHub releases.

 

Optional Hotkey and Snippet Triggers:

 

Customize the workflow with either a custom hotkey or a custom snippet.

 

Links:

 

• GitHub Project
• Download New Releases
• GitHub Issues - (please submit bug reports and feature requests here)

 

Screenshot:

 

 

Edited September 27, 2019 by Ryan McGeary
Added v1.8.0 download link

[cands]

Great, thanks! It's working well. A few suggestions for improvements if you have time/possibility: 

Add "paste" as an option if e.g. ⌘ is pressed (as an alternative to copy). 

Add an auto-update mechanism, e.g. this:

 

[Ryan McGeary]

Quote

 

Add "paste" as an option if e.g. ⌘ is pressed (as an alternative to copy). 

 

 

@cands Could you please elaborate on this? Do you have an example of another workflow that does this?

 

Quote

 

Add an auto-update mechanism

 

 

I'm all for auto-updating, but until Alfred supports this directly, I'm not a huge fan of relying on a 3rd party dependency for that functionality. Ideally, Alfred might add new fields in the info.plist to trigger auto-updates in a very similar conventional way as AlfredWorkflow does it. 

[deanishe]

4 hours ago, Ryan McGeary said:

Alfred might add new fields in the info.plist to trigger auto-updates

 

That is basically what OneUpdater does. You give it the URL of your info.plist and .alfredworkflow file, and when the former changes, it downloads the latter.

 

As far as external dependencies go, OneUpdater has fewer than Alfred-Workflow, which only works with GitHub releases. OneUpdater is a small, self-contained script that doesn’t care which language your workflow is written in or where it’s hosted.

 

[Ryan McGeary]

@deanishe ? Skimming the docs, OneUpdater violates some good release management principles. If using GitHub, it effectively requires that the binary *.workflow be put in the repository instead of properly assigning it to a versioned/tagged release asset. Alfred-Workflow does a much better job with this, but it has other cons. 

 

As much as I'd like to incorporate an auto-updater, neither of these packages look entirely clean. Again, it'd be great if this was just built into Alfred core. I'll noodle on it some more though. Maybe sleeping on it will change my mind. 

[deanishe]

8 hours ago, Ryan McGeary said:

If using GitHub

 

Well, yeah. It's not designed around GitHub, and Vítor doesn't use releases, as he's one of many developers who keep all their workflows in a single repo. That said, there is a version that does use GH releases.

 

8 hours ago, Ryan McGeary said:

Alfred-Workflow does a much better job with this, but it has other cons

 

Namely?

[carnegie]

Great workflow, thanks! Is there a way to auto-expand/paste it once I select an emoji?

[cands]

On 08/01/2018 at 7:54 PM, Ryan McGeary said:

Could you please elaborate on this? Do you have an example of another workflow that does this?

 

Sure, this is easy (my description may not have been clear), I meant just add another "Copy to Clipboard" action with an action modifier (e.g. set to ⌘) and select "Automatically paste to frontmost app", as the below screenshots show (for your workflow). This could be done by the individual users, but I think it would be more handy if already included in your workflow.

 

[deanishe]

On 09/01/2018 at 2:44 AM, Ryan McGeary said:

I'll noodle on it some more though. Maybe sleeping on it will change my mind.

 

Purely out of interest, did you come up with anything?

 

(I'm also still interested in what you consider the cons of Alfred-Workflow's update mechanism, as I could perhaps address them. A much more modular version 2 is somewhat overdue, and that provides a rare opportunity to make changes to the API.)

Edited January 10, 2018 by deanishe

[Ryan McGeary]

7 hours ago, deanishe said:

Purely out of interest, did you come up with anything?

 

(I'm also still interested in what you consider the cons of Alfred-Workflow's update mechanism, as I could perhaps address them. A much more modular version 2 is somewhat overdue, and that provides a rare opportunity to make changes to the API.)

 

Not specifically. I'm not the original author. Just a new collaborator on the project. I'd love to incorporate auto-updating, but I'm still not crazy about the current solutions. 

 

The con of Alfred-Workflow is mainly just that it requires python and a lot of extra overhead to get auto-updating support for a workflow that doesn't depend on Alfred-Workflow in the first place.

 

Again, I'd much prefer that Alfred build this in directly. 3rd party support for something like this just opens up the potential for security issues. Auto-updaters should do just one thing, and ideally, they should come from the same trusted environment as the original software. OneUpdater comes close, but in a very clever way. Clever isn't always good. Also, unless I'm misunderstanding its basic usage, at a minimum, OneUpdater needs to support `version` variable substitution (extracted from the downloaded plist) into the `workflow_url` setting so it can support tagged release downloads on GitHub.

 

Edited January 11, 2018 by Ryan McGeary

[Ryan McGeary]

2 hours ago, cands said:

I meant just add another "Copy to Clipboard" action with an action modifier (e.g. set to ⌘) and select "Automatically paste to frontmost app"

 

Ah! I understand now. Yes, I like this. I'll try to add it soon. Thanks for the suggestion!

[Ryan McGeary]

12 hours ago, carnegie said:

Great workflow, thanks! Is there a way to auto-expand/paste it once I select an emoji?

 

On 1/7/2018 at 2:56 PM, cands said:

Add "paste" as an option if e.g. ⌘ is pressed (as an alternative to copy). 

 

v1.3.0 now has automatic paste support into frontmost application if ⌘ (cmd) is pressed!

[deanishe]

37 minutes ago, Ryan McGeary said:

The con of Alfred-Workflow is mainly just that it requires python and a lot of extra overhead to get auto-updating support for a workflow that doesn't depend on Alfred-Workflow in the first place.

 

In most respects, the Python requirement is a non-issue, as Python is a default part of macOS. Zero dependencies (outside of macOS and Alfred) is a core goal of the library because it offended my sensibilities to see so many workflows bundling the same stuff over and over again.

 

But the update mechanism is certainly overly dependent on other parts of the library (for today's Alfred). The library is very monolithic because when it was designed, it was necessary to parse info.plist to get data that are now available via environment variables, and I wanted to avoid parsing it multiple times for performance reasons.

 

That's why I'm looking for input to help with designing a more flexible API. Like whether it's worth making update.py work as a standalone updater for GitHub-based workflows, regardless of whether they use AW (or even Python).

 

[deanishe]

20 hours ago, Ryan McGeary said:

3rd party support for something like this just opens up the potential for security issues.

 

What makes you say that, btw? The updaters themselves are provided as (non-obfuscated) source code, and are short and simple enough to easily verify that they aren't doing anything shady. It seems to me that all the risk comes from a malicious workflow or hacked GitHub account, not the updaters.

 

All of npm's security issues have been caused by the (design of the) npmjs.com service, not the client(s).

 

20 hours ago, Ryan McGeary said:

they should come from the same trusted environment as the original software

 

What do you think Alfred could do to improve security on this front? As long as the update client is using HTTPS and verifying SSL certs, there doesn't seem a whole lot else that can be done client-side (unless the Alfred team starts vetting workflows, which isn't realistically possible).

[Ryan McGeary]

4 minutes ago, deanishe said:

What do you think Alfred could do to improve security on this front?

 

Require signed/verified releases. Similar to what the App Store does, but Alfred could just delegate to GitHub as a verification authority.  The devil is in the details here, but any releases that aren't signed might just present a warning.

 

7 minutes ago, deanishe said:

What makes you say that, btw? The updaters themselves are provided as (non-obfuscated) source code, and are short and simple enough

 

OneUpdater meets that short-n-simple criteria, but AlfredWorkflow does not (the update functionality is nested inside a lot of other functionality, and auditing it isn't worth most people's time; even though, I really like the AlfredWorkflow update conventions). Furthermore, for workflows that are not already python-based, AlfredWorkflow isn't that approachable.

 

With all that said, your continued nudges have forced me to read the source of both ?. I just found a feature in OneUpdater that I think would meet my criteria for github releases. 

[Ryan McGeary]

3 minutes ago, Ryan McGeary said:

With all that said, your continued nudges have forced me to read the source of both ?. I just found a feature in OneUpdater that I think would meet my criteria for github releases. 

 

Whoops. I spoke too soon. Even with OneUpdater's github-release feature, it requires that new version numbers come from a static plist file, but ours is variable substituted during each build:

https://github.com/jsumners/alfred-emoji/blob/master/src/info.plist.xml#L155-L156

 

Maybe, I'll consider a pull-request to OneUpdater to remedy this such that if you specify github release downloads, the script only looks at the github API for new tagged versions (ignoring the need for a static plist file sitting somewhere).

[deanishe]

 

2 minutes ago, Ryan McGeary said:

Require signed/verified releases. Similar to what the App Store does, but Alfred could just delegate to GitHub as a verification authority.

 

If Alfred gets its own built-in updater, I'm not sure it could use GH releases (at least not exclusively).

 

Signing could certainly prevent some potential issues.

 

14 minutes ago, Ryan McGeary said:

Whoops. I spoke too soon. Even with OneUpdater's github-release feature, it requires that new version numbers come from a static plist file, but ours is variable substituted during each build

 

I think the usual way is to do it the other way around and have the canonical version number in info.plist and read it from there if you need it somewhere else.

 

Could you not leave a copy of the generated info.plist alongside the template for OneUpdater to use?

[Ryan McGeary]

1 hour ago, deanishe said:

Could you not leave a copy of the generated info.plist alongside the template for OneUpdater to use?

 

No, that defeats the purpose of good, clean version control (i.e. never put compiled assets in your repository).  I actually just took the OneUpdater script and heavily modified and simplified it. I now have a working script that is smaller than OneUpdater, but follows the same, good GitHub release conventions as Alfred-Workflow. Here's the PR, if you're interested:

https://github.com/jsumners/alfred-emoji/pull/14

[Ryan McGeary]

Automatic Updates are now part of v1.4.0. Enjoy!

https://github.com/jsumners/alfred-emoji/releases

 

(this will be best realized when new emoji are released)

[deanishe]

6 hours ago, Ryan McGeary said:

No, that defeats the purpose of good, clean version control (i.e. never put compiled assets in your repository)

 

It also means your repo doesn't contain an info.plist, the file containing all the workflow's (meta)data.

 

In any case, nice update.

 

Which font do you use in Alfred? I'm getting Copy "[?]" … for quite a few emoji (in the subtitle). Or is that just because I'm not on High Sierra?

[Ryan McGeary]

11 minutes ago, deanishe said:

It also means your repo doesn't contain an info.plist, the file containing all the workflow's (meta)data.

 

 

https://github.com/jsumners/alfred-emoji/blob/master/src/info.plist.xml It's just that PList XML files should really only be computer manipulated (PList XML is actually quite a terrible file format)...and that's what build scripts are for. It's generally considered best practice that you don't commit files that could otherwise be rebuilt by the build.

 

13 minutes ago, deanishe said:

Which font do you use in Alfred? I'm getting Copy "[?]" … for quite a few emoji (in the subtitle). Or is that just because I'm not on High Sierra?

 

I believe the newer emojis like "dumpling" (?) are only available on High Sierra. I think they're upgraded as part of macOS and iOS updates.

[deanishe]

1 hour ago, Ryan McGeary said:

It's just that PList XML files should really only be computer manipulated

 

 I know that file is in there, and I'm not arguing anyone should edit it by hand.

 

What I'm saying is, it isn't called info.plist and isn't valid (in the sense that the version string in it is nonsense). Presumably, this causes issues when editing the workflow (changes made in Alfred's UI need to be copied over to the template somehow), and as you've seen, it can cause issues with Alfred tooling (which expects there to be an info.plist).

 

1 hour ago, Ryan McGeary said:

It's generally considered best practice that you don't commit files that could otherwise be rebuilt by the build.

 

I know. I'm saying that it's also considered best practice to have the real info.plist in your repo (for the above reason).

 

In any case, both best practices can usually be followed by using /usr/libexec/PlistBuddy -c "Set :version \"X.Y.Z\"" info.plist to update the file in place instead of generating it from a template.

 

That way, you can work with the "real" info.plist when editing the workflow in Alfred, and just have your build script and/or commit hooks update the version number (or strip any API keys or whatever).

 

1 hour ago, Ryan McGeary said:

I believe the newer emojis like "dumpling" (?) are only available on High Sierra. I think they're upgraded as part of macOS and iOS updates.

 

I'm pretty sure you're right. I just checked your post on my up-to-date iPhone and I can see something not at all like a dumpling. On my Mac, I just see the "unsupported Unicode" box  

Edited January 12, 2018 by deanishe

[jsumners]

/sigh I really didn't want to have to create yet another account, but it looks like I need to step in and clear up some confusion.

 

`alfred-emoji` does not get directly edited within Alfred. Therefore, there is no need to keep the "real info.plist" around in the repository. Yes, it is ***very*** frustrating that Alfred's info.plist schema is not documented anywhere and to add new things (e.g. a hotkey item) requires tinkering around in Alfred to figure out what it does to the plist. But it's far easier to do that tinkering and then migrate the differences to the *very rarely* changing source XML than it is to constantly try to keep the "real info.plist" in sync with the source repository.

 

In short: I setup the repository as an actual project and not some poke-and-prod thing that Alfred workflow development necessitates. Typical Alfred workflow developers may not like that, but I will take the benevolent dictator approach and reject any change to the contrary.

[nikivi]

I just realised that this workflow weights 44 MB because of embedded node. That's wild.

 

I use this workflow for searching emojis + unicode symbols that is really nice. Might not have the latest emojis though.

[nikivi]

Would it be possible to use Sindre's approach to node workflows. Like what he does with Alfred NPM.

 

He calls the Script Filter with: ./node_modules/.bin/run-node.

 

Where run-node script is this. I think this will let you avoid bundling node with the workflow.

Edited January 12, 2018 by nikivi