Andrew

It looks like Apple have mostly fixed this in Big Sur.

Urghh, thanks for spotting this before 4.1.1 was released, it has been directly caused by this: I'll take a deeper look at this in the morning. Cheers, Andrew

@rascalroots In your video, I can see that you're not straight downloading the workflow file, you're opening it with archive utility, which is changing what you've downloaded. In the Firefox popup, select "Save File" instead, and save it to your desktop, then you'll get the actual workflow file with a .alfredworkflow extension, and an Alfred icon. This should import into Alfred just fine. Also, try downloading and installing one of our workflows to make sure there isn't something installed on your Mac which is interfering with Alfred's file type (as it conforms to public.zip-archive so 3rd party unarchiving utilities can break things). There is a simple workflow you could try here: https://www.alfredapp.com/blog/tips-and-tricks/flip-everything/ Cheers, Andrew

@bbq Have you checked your macOS Language & Region settings in the macOS System Preferences? Alfred is given the words and definitions to show by macOS, he doesn't maintain his own dictionary. I'm moving this to the Discussion and Help section to see if anybody may have an idea why macOS isn't suggesting more words. Cheers, Andrew

@bbq Could you check the language you have set is the same in Alfred's Features > Dictionary preferences. Also, you can quit Alfred and re-download the 4.1 build directly from Alfred's homepage, and simply replace the Alfred.app bundle in /Applications/. If you do this, let me know if the behaviour stays the same

@eozzy what behaviour do you get if you set the snippet to be plain text (which should match the destination formatting). Also, what behaviour do you get when pasting into Apple's TextEdit app. I suspect this is more likely a quirk in Outlook.

@nikivi I believe the .icloud extension is a generic one which denotes a file is currently not on your Mac. The bug in macOS is that when you double click a .icloud file in Finder, it downloads it then opens it in the app of the real file type, e.g. a pdf. If you request to open this icloud file via the macOS cocoa API, macOS asks you to associate the .icloud file with an app, which is wrong, as any file type could have an icloud extension. It looks like you associated this generic icloud type with PDF Expert, which I think is wrong. When I say associate the .icloud files with Finder, I'm wondering if that would be the same as using cmd+o on any file with a .icloud extension, which you say downloads first then opens it. My other alternative suggestion was finding out if you can hand that file off to Finder to open with AppleScript. I haven't been able to test this as I can't get offloaded icloud files on my Mac. If anybody knows how to force this, let me know!

I'm talking about a similar thing. If you use a Run Script object instead, and configure it to use an external script, then you get a button to open that script in your default associated editor. Depending on how you have your editor configured, this will also take you to the folder tree for that file. If the script is not set as External in somebody's workflow, then you wouldn't be able to edit that script externally anyway because the script isn't in a separate file. Having said that, I do see what you're talking about for being able to open the workflow folder in a different app from the button next to the cancel button.

@flowflow The workflow objects I describe allow for what you describe: https://www.alfredapp.com/help/workflows/actions/file-buffer/ and... https://www.alfredapp.com/help/workflows/actions/action-in-alfred/ You can configure an Alfred hotkey to take a selection in any app and add it to Alfred's buffer. As for the CLI, you can use an External Trigger or Inbound Configuration to provide scripting access using AppleScript / Javascript (from the command line) to any point within a workflow, including the file buffer: https://www.alfredapp.com/help/workflows/inbound-configuration/ https://www.alfredapp.com/help/workflows/triggers/external/ The thing you can't do is single out an item in the buffer to action though.

@chris If you use a Run Script instead of the Run Apple Script, then select "External Script" as the language, then you get an "Open File" option, and your editing is done externally. It's also worth noting that the Run Apple Script blocks Alfred until the script completes, so unless it's a very fast script, it's advisable to use Run Script instead anyway.

Most of these things are possible, especially with the additions in 4.1. While dragging in isn't possible, in 4.1, you can configure a workflow for a hotkey combo to add the selected file (or typed path) directly to the file buffer using the new File Buffer action Again, this is possible using the same method as above, but wiring into the new Action in Alfred action. Alternatively, if you find a single file in Alfred and press right, then it will action that single item rather than alt+right to action all If you hover over the item you want to remove, hold alt, then click that single item, it will remove it. See the File Buffer and Action in Alfred workflow objects. Cheers, Andrew

This is so blatantly a bug in Apple's API for opening files, as it should never be asking for the app to open their own .iCloud files. Have you tried associating .iCloud files with finder? As Finder seems to download these files before opening them. Alternatively, perhaps some AppleScript to tell Finder to open the .iCloud file to see if that instigates the download. I can't see how to get my Mac to force offload a file to iCloud (to get a .iCloud file), so I can't test this for myself, but if one of these methods works, I could look at adding a workaround into Alfred.

If you update to the 4.1.1 pre-release, there is now an option under the { } snippet placeholder button which allows you to disable dynamic placeholder expansion per scenario. If you update, could you let me know how you get on

@millerstevew could you please update to the 4.1.1 pre-release and let me know if those spaces are now gone? Cheers, Andrew

@superMe this should now be fixed in the 4.1.1 pre-release

The 4.1.1 pre-release should now handle this better, could you let me know?

In the 4.1.1 pre-release, Alfred will now interpret file: URL strings, so you may see better behaviour here. Essentially, Dean has correctly summarised this situation, and it's unlikely Alfred will accept arbitrary types here.

@Karl87 I had slowed it down a little, and now it's pretty similar to double clicking the mouse. For merging, are you holding the cmd key, then tapping C twice? You have to be quite slow to not get a merge. Cheers, Andrew

I've added an addition for the upcoming 4.1.1 from the { } button popup menu (bottom left of relevant text fields) to allow for disabling of dynamic placeholders for the current item your configuring. This works in all areas where there is the { } button, such as Workflow Copy to Clipboard, Write File, Large Type, then Remote Clipboard / Snippet, and finally the Snippets. I should have a 4.1.1 pre-release out by next week

@gingerbeardman unfortunately, this isn't a simple fix, as may of Alfred's preferences panels have a minimum width due to quantity of content and layout. I'll keep this in mind for the future though.

@RobertF this would be possible with a Workflow. If you pop your Powerpack email address in your forum profile, then I can help you further

Is this issue Google Drive specific for you? If so, take a look at this thread:

If the app is linked into the Applications folder, you simply need to add the original path (or a parent of the original path) to Alfred's Features > Default Results > Search Scope.

The simple answer to this is Alfred Remote *will* get a major update, but I can't give you a timescale. To keep Alfred's quality as high as possible, we are extremely selective over which features bring the most value to our wider user base. Alfred Remote constitutes a minor part of this user base, so while we have continued to add features to Remove via updates in Alfred itself, the core Alfred Remote app has remained as is. While it would be nice to do a minor update to Remote to include some of the newer iOS features, Apple has evolved iOS significantly since Remote was originally released, with some technologies deprecated, and some new ones introduced, so Remote would need an overhaul to fit with within Apple's framework and "vision", all while trying to keep Remote backwards compatible with Alfred 3. Over the past number of years, I've been keeping a close eye on Swift and Swift UI, and this may provide a perfect platform for a complete Alfred Remote rewrite, but it could be too early to allow this to work on a wider number of older devices. As I said before, when Alfred Remote version 2 comes out, I'd like to keep it as a free update for all current Alfred Remote users.

@dentarg when you see anything locking secure entry, this is unfortunately outside of Alfred's control and simply means macOS is no longer feeding accessibility events to any app, including Alfred. loginwindow is an interesting one as it can also mean an ancestor of this, such as the password coming back from screensaver. Either way, you may need to restart, or at least logout/in to try and flush that through if quitting all other apps doesn't help, and after this, you may never see it again.