Jump to content

deanishe

Community Hero
  • Content Count

    5,896
  • Joined

  • Last visited

  • Days Won

    348

Everything posted by deanishe

  1. That's very useful to know. I wondered if there was a command-line flag for it, but I didn't realise that you can also pass them via open. Perhaps the API Alfred uses also supports them, then?
  2. I think I hate modern macOS. Yeah. You can't have such a core action being slow.
  3. Could Alfred not check if the app has any windows open, and then activate or open accordingly? Or is that too slow? The same behaviour as messages is fairly common amongst document-based apps, like browsers and editors, I believe.
  4. By that you mean the window that has that specific file open in it, right? Yes, that's possible to do via Excel's AppleScript API. You can check if the application is running, and Excel's AppleScript API allows you to tell which documents are open in which windows. So you could probably create a workflow. First of all, you should report the bug to Microsoft, though.
  5. That's a no-go, then, unless the plugin keeps its data in the Zotero database, because that's what the workflow reads. Currently, all citations are formatted using CSL stylesheets, too. If you can use a "scannable cite" CSL style, that's what you should do.
  6. Afraid not. Chrome doesn't provide any way to tell it to use a specific profile.
  7. @garyh The latter possibility intrigued me, so I wrote a script that imports your Pinboard bookmarks into a Chrome profile. If you create a new Chrome profile and point the script at it, you can have your Pinboard bookmarks directly in Alfred's default results. Obviously, you lose the benefits of tags, though.
  8. You can't directly plug workflow output into Alfred's default results. To do that, you'd need to export the data to .webloc files or create a "fake" browser bookmarks file, e.g. create a new Chrome profile and overwrite its Bookmarks file with your Pinboard bookmarks (in Chrome bookmarks format).
  9. You can't: the domain doesn't exist any more. I've no idea why you're seeing that searchguide.level3.com. It's probably something your ISP/DNS-provider is doing when your request a non-existent domain.
  10. That's normal, tbh. It's insane. It'd probably be a better use of your time trying to re-implement your workflow in a sensible language (if that's possible) than muddling through with AppleScript. It's so crazy, I still don't really understand it after using it for years.
  11. What are you trying to achieve, exactly? Why can't you use one of the existing Pinboard workflows like the one you linked to?
  12. Yes, it's possible. You can chain Keywords/List Filters/Script Filters together to form multi-step workflows, using variables to save the results of each step.
  13. Mine shows search suggestions. This one scrapes the actual search results from the webpage. That's the reason it breaks quite often.
  14. No, I mean creating a workflow in Alfred and adding a File Action to it, which would show up in Alfred's list of file actions (alongside Open With…), but not in Finder or any other app.
  15. This simplest solution (imo), which is what I did for the app that I had problems with, is to implement your own File Action that calls the app with all files at once. It's basically just a File Action connected to a Run Script with Language = /bin/zsh and the script open -a YourApplication $@, and has the bonus that you can call the action directly without first going through Alfred's Open With… menu.
  16. It does (unless something has changed). I previously reported the same issue with another application, but as I remember, sending all the files at once cause problems with other applications, and Andrew deemed breaking working apps a worse choice than fixing ones that didn't work. I don't remember the exact details, though, and it was a good few years ago, so the circumstances may have changed, and @Andrew might consider revisiting the issue?
  17. As I understand it, it's not the actual filtering that's an issue, it's retrieving the metadata for the search results from the metadata API that are required to do the filtering in the first place. Say, for example, you search for "index.js", the API will return (hundreds of) thousands of results if you have some Node projects. The API only returns "handles" for the results, which is very fast. The application (Alfred) then has to separately request the actual metadata for each result it's interested in. This is the slow bit, so Alfred tries to retrieve the metadata for as few files as possible. So excluding node_modules from a search of your Node projects (which really is a worst-case-scenario for a search system set up this way) would mean Alfred has to fully load many, many thousands of results just to throw 95% or more of them away. Which would be terribly slow in any case. A better solution (for the Node case, at least) would be to write yourself a workflow based on ripgrep or some other gitignore-aware search tool. The best solution would probably be yarn 2, as @Paul Razvan Berg suggested above. The whole Node idea of plopping all your app's dependencies in the project folder is okay for deployment, but a silly way to develop (given the stupendous number of dependencies that typical Node apps have).
  18. Perhaps I've misunderstood your problem. The script is designed to open the URLs in tabs in a new window. If you want to open the URLs in an existing window, delete this section of the script: tell application "System Events" to tell application process "Firefox" set oldNbrOfWindow to (count of windows) keystroke "n" using command down repeat 20 times if ((count of windows) > oldNbrOfWindow) then exit repeat delay 0.1 end repeat end tell
  19. env only runs programs on PATH, and the entire problem here was that the program isn't on PATH. Alfred doesn't use the same environment as your shell because it isn't run from your shell, so if your program isn't in /bin or /usr/bin, it must be called by its full path, not just its name, from within Alfred (and other Mac apps).
  20. It can't really be done for implementation reasons (the library stores machine-specific data in the settings file). It would also break the API, which is a no-go. Finally, it's not clear that syncing the data are better than not syncing them. In some cases, sure. But not in all. It's likely that I'll add a separate API for writing to a folder within the prefs bundle at some point in the future.
  21. Nope, I don't think so. Parsing all the info.plist files is the most reasonable option, and it's not entirely straightforward unless you're doing it in ObjC/Swift:
  22. EDIT: Ignore me. I don't know what I'm talking about. Hi Pete, welcome to the forum. Nope. Text only, I'm afraid.
×
×
  • Create New...