xilopaint

Anyone interested on AppleScript support for Warp can give a 👍 in the original post of this issue: https://github.com/warpdotdev/Warp/issues/3364. It helps the team to prioritize it.

Just released a workflow for checking disk usage. It’s a major improvement from the one shared above, faster with better icons.

This would be a useful feature, but it should be "Open in Editor". The custom integration for the editor could be similar to what we have for terminals.

There are some plans for additional URI, but no ETA from Warp team.

I just tried with a second file. This time the process has been completed with the “Word Granularity” strategy but the OCR quality with "Line Oriented" is way better.
 
 
It doesn't matter. After clearing the cache I always face the same issue with “Word Granularity” if I run the workflow with the first PDF file.

Sure, why not 😄
 
v1.3.0
- Added browser selection to workflow configuration 
 

By using Alfred’s official question mark search you can jump straight to a keyword (or Script Filter and others) even if it’s defined from a variable.
 
Making keywords configurable via variables is indeed recommended and documented.

You can! By default, the workflow only displays CPU and memory if the values above a threshold to reduce noise. But if you want to always see them, you can just set the respective settings to 0:

This is a cool feature. I'll be updating my workflows with this as soon as 5.1.2 gets stable.

Worth noting, as a note on the note, that Alfred includes both Homebrew paths in its PATH. This allows you to use the name of the tool without the full path and not have to worry about that distinction, meaning less things to worry about as a creator and less configuration for users to do.

Also worth mentioning (though I don’t think it applies here, it’s just as a curiosity) that /usr/local/bin is a standard location that’s used by non-Homebrew tools as well (e.g. a GUI app installing its own CLI, I think VS Code does exactly that). Homebrew used that path despite that because otherwise (at the time this was implemented) a ton of tools wouldn’t work correctly anywhere else. Thankfully that situation has improved, so the transition to /opt/homebrew has gone well and it leads to fewer (albeit rare) conflicts.
 

Usage

Search workflows in the Alfred Gallery via the gallery keyword.


↩: Open Gallery page in default browser. ⌃: Show tags. ⌘↩: Install workflow. ⌥↩: Narrow search to creator’s name. ⌘Y (or tap ⇧): Quick Look workflow’s Gallery page.
⤓ Install on the Alfred Gallery | Source

Do brew install multimarkdown and install this version. Let’s see if that solves it.

Now, it's working. Thank you so much 💐.  

Updated to 2023.2.
Add support for Orion. Add support for Arc. Exclude live chat info.

Hey @xilopaint! Unfortunately this is not possible at the moment as I am using folderify cli under the hood which do not allow color modification. But this is a good enhancement to submit to Igarron the creator of folderify cli.

The issue has been fixed on macOS 13.4.

Indeed it did. The other one died.
 
 
Great! That is indeed expected, especially if you set your store in the workflow itself.
 

The issue has been fixed on macOS 13.4.

YouTube Search

  
 

An Alfred workflow to search YouTube.

Setup

The workflow requires an API key, which can be requested and set up by following the steps 1–3 that you can find here.

Usage
 
Search videos via the yt keyword, channels via the ytc keyword, and zplaylists via the ytp keyword.
 
When displaying channels, select one of them and use the ⌘ modifier key to show its description.

Contribute

To report a bug or request a feature, please create an issue or submit a pull request.
 

@xilopaint WeWorkflow also does that

I'm absolutely in love with this workflow. I like everything, even the icon color tone is appealing to me. Haven't you committed the code for the compression feature @zeitlings?
 
What kind of compression are you doing, btw? Is it similar to the work of my workflow’s optimize action you mentioned earlier?
 

@TomBenz I just updated the workflow to include compression. 
 
If you remember the 1.2 MB sample you sent me, it blew up to 7.9 MB uncompressed. With compression, we level off at 589 KB on my machine without butchering the file 😁. However, compressing a PDF does not always result in a smaller file size, so I've decided to keep the uncompressed PDF document around if compression does not actually produce the desired result. Let me know what happens to the 1.15 GB document!
 
I've decoupled the compression utility, which means you can now compress any PDF without having to run OCR on it. For some documents this works really well, for others it may inflate the file size even more. Which factors play a role here remains a task for future experiments to find out... There are also some internal improvements, additions to the workflow and tweaks:
 
v1.3.0 (OCR+)
Added PDF compression Added a keyword for quick access to the workflow configuration (Alfred 5.1+) Added Universal Action modifier option to apply compression to PDFs (⇧⌘) Added Universal Action modifier option to open converted PDFs in the default application (⌥⇧) Added a configuration option to open converted PDFs in the default application Added a configuration option to specify how text should be joined when taking a snapshot Added a File Action to compress PDF documents Changed the modifier keys to replace a PDF and added noticeable visual queues (⌥⌘) Changed the way an export strategy is specified by using a pop-up selection box Improved performance

Can anyone confirm whether the bug persists in Ventura? My PDF custom icons are not being displayed as well.
 

Btw, I noticed the issue after installing Skim and changing the filetype association. Perhaps the bug can be related to Ventura not handling properly filetype association changes.

I also confirm I see the same.
 
Stephen

Yes I have a new MacBook that came pre-installed with Ventura and this issue persists to this day.