Jump to content

Ryan McGeary

Member
  • Content Count

    22
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Ryan McGeary

  1. @bivalvegruff See https://github.com/jsumners/alfred-emoji/issues/35. We're waiting on some upstream dependencies before we can do this.
  2. Very unlikely. I think that would violate the POLA. The default behavior of Alfred is to add items to the clipboard upon hitting [return]. I suggest using a keyword snippet instead. If the workflow is instantiated from a keyword snippet, it automatically pastes. Yes, that already exists. Assuming that you have at least v1.6.0 installed, just set the `snippetapp` environment variable (to any value) in the workflow configuration to change the behavior to always paste the emoji character regardless of how the workflow is instantiated.
  3. Could someone please confirm that what I perceived as a bug is actually considered a bug? /cc @Vero @Andrew
  4. v1.6.0 now has custom snippet support. Thanks to @deanishe for the suggestion. https://github.com/jsumners/alfred-emoji/releases/tag/v1.6.0
  5. When upgrading a workflow, if "Migrate my settings" is checked, settings such as custom keyword inputs and custom hotkeys are kept; however, if a keyword is customized and the associated "with space" setting is also customized, the "with space" setting is not migrated during the upgrade. I expected that the "with space" setting would migrate just like the keyword migrates. As an example, when I upgrade Alfred Emoji, I change my keyword from "emoji" to to a single character (:), but I also uncheck the "with space" setting, because I want to emulate emoji completion in tools like GitHub or Slack. Alfred version & build number: v3.5.1 [883] OS X version: 10.13.2 (17C205)
  6. Great suggestion! Try the newly released v1.5.0. https://github.com/jsumners/alfred-emoji/releases/tag/v1.5.0
  7. Good point regarding using the mac tools for manipulating the XML. But, it's probably best to use /usr/bin/plutil, because that's actually in a directory originally intended for interactive command line execution. ?. Yes, German-style dumplings are very different from dumplings (and variants like pierogies) ? around the rest of the world. I say no. You cannot guarantee that someone already has node.js installed on their machine. Not to mention, every version of node varies in functionality quite a bit. You could always code to the least common denominator of Node LTS, but that would also be a support nightmare when people simply install an out-of-date version. It's not ideal that the workflow size is big (18MB zipped), but we can guarantee that it will work on everyone's machine within nothing more than a standard *.alfredworkflow install. Btw, most Alfred workflows suffer from this least-common-denominator language versioning issue by not being able to specify runtime versions. Now, what might be more interesting would be to write an alternative script to `run-node` that lazily installs node in real-time if it cannot find a reasonable runtime.
  8. 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. 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.
  9. 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)
  10. 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
  11. 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).
  12. 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. 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.
  13. v1.3.0 now has automatic paste support into frontmost application if ⌘ (cmd) is pressed!
  14. Ah! I understand now. Yes, I like this. I'll try to add it soon. Thanks for the suggestion!
  15. 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.
  16. @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.
  17. @cands Could you please elaborate on this? Do you have an example of another workflow that does this? 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.
  18. 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:
  19. @Vero Thanks for chiming in, but I've already previewed the specific guide you're referring to. What I'm missing is how to insert the contents of multiple snippets into one over-arching wider piece of content. i.e. What workflow action gathers other snippets by name? And how do I gather multiple snippets and combine them into one larger snippet including multiple other snippet inputs? I guess I failed to find that. The whole notion of snippet workflows sounds really powerful for certain tasks, but it also feels quite convoluted from the perspective of just combining smaller snippets into one larger snippet. Maybe a more concrete example will help. Let's say that I have two small snippets: one for my business address and one my business Tax Identification number: .addr = 123 Fake St, Denver, CO 80014 .taxid = 12-3456789 Just like I can insert a {date} or {clipboard} into another larger snippet, I'd also really like to build a snippet that can output the combination of other snippets (using them like variables). Here's a somewhat contrived example of what I'd ideally be looking to do: Thank you for your business. Please send payment to: {snippet:.addr}. My business Tax ID is {snippet:.taxid} And to be more clear, these snippets might be further nested. e.g. I'd prefer my .addr snippet to be composed of smaller snippets like .as = (address street), .ac = (address city), and .az = (address zip), because I often use those to fill in forms that require them to be separated.
  20. With the new features in Alfred Snippets, I'm considering consolidating all my snippets from aText into Alfred. One feature that I use often in aText is the ability to embed a snippet inside another snippet expansion. This allows me to treat smaller snippets as variables that can be reused in other larger snippets. Is this possible with Alfred's Snippets?
×
×
  • Create New...