Andrew

@cstsoi thanks for the update on this - the bug reports I had made to Apple were closed as fixed for 10.13.2, so it looks like the three issues I documented in our bug forum have now been fixed: Cheers, Andrew

@Sridhar Katakam take a look at this workflow object: https://www.alfredapp.com/help/workflows/triggers/hotkey/ You can set the argument as the currently selected text in macOS, then configure Alfred to either show with this, or to pass this into the workflow Cheers, Andrew

@politicus the iTerm script is a little more involving than this, take a look at this blog post: https://www.alfredapp.com/blog/tips-and-tricks/better-iterm-integration-in-alfred/ Which links to some pre-baked iTerm scripts: https://github.com/stuartcryan/custom-iterm-applescripts-for-alfred Cheers, Andrew

@Heydomdom I've quickly thrown together a workflow which achieves what you're asking for: https://www.dropbox.com/s/lbqsg4jhyrcw2f4/Google Stock.alfredworkflow?dl=0 You'll be able to edit the simple script to your liking Cheers, Andrew

@Jim Wood Users have been reporting this as a Google Chrome bug after Chrome has updated in the background, where URLs aren't being opened (from any source, not just Alfred). You just need to relaunch Chrome. Cheers, Andrew

@deanishe Alfred doesn't unsubscribe, but idles on the events, only acting on the grouped events when they become relevant (i.e. Alfred needs the changes). Alfred only subscribes to the top level Alfred Preferences file, not multiple paths, so this will be why there may be reload issues with symlinked workflows. I can see that Alfred needs these things: 1. Setting a workflow configuration variable, which will write the variable to the info plist. 2. Forcing a reload of a workflow, which will get Alfred to reload a workflow e.g. if a symlinked info plist is externally updated via github It pains me to say that, for now, this may be done through Alfred's AppleScript interface, as the framework for this already exists. I do have much bigger plans for the future for this area though.

@effe2402 take a look in Alfred's Appearance > Options (bottom left button). There are a few options for where to show Alfred on the right hand side of that sheet: "Default Screen", "Mouse Screen", "Active Screen" Cheers, Andrew

@deanishe sorry about the slow reply on this, I've been mulling it over for a while. It's a very unusual and unexpected situation to have the syncfolder variable set but for Alfred not to be using this sync folder (because the folder tree doesn't exist). There are a few reasons Alfred doesn't reset the syncfolder at the point the [folder tree to the] Alfred preferences don't exist (e.g. temporarily unavailability of external drive), and when this does happen, the behaviour is likely quirky anyway. It's hard to say how many people may be affected by me changing this behaviour, and removing syncfolder pref if the tree doesn't exist. I'll continue to mull

@Jaap Noordzij I've just verified on our 10.13 test machine and it works as expected. Alfred uses AppleScript to pass file interactions off to finder, and an error like this suggests that AppleScript / OSAScript has simply stopped working on your Mac. Have you tried restarting? This may get things working again. Cheers, Andrew

@deanishe I wonder why symlinked workflows take that long to update, I'd have to look into that. Alfred is fed filesystem notifications from macOS when there is an update Alfred should be aware of (this mechanism is also used for the syncing), and Alfred sets the grouping param to 5 seconds, so it shouldn't be any slower than this. I wonder if symlinked ones aren't even getting notifications at all, and it's an alternative mechanism (there are a few others) which is reloading the info plist at that time. I'll add a ticket and have a bit of a think into this Cheers, Andrew

@Steve Ball thanks for giving this update! @iandol have you tried running with alt+space yet?

This is now going to be tracked in this bug thread (beta build available), please add any further replies here:

This is now going to be tracked in this bug thread (beta build available), please add any further replies here:

This is now being tracked in this thread: [moving to closed]

[moving to closed as this is now being tracked in the thread above]

@qraig Grab the beta build in this thread, then keep an eye on this thread for any updates:

UPDATE NOTE: The macOS bug report for (1) below has been closed by Apple, so this should now be fixed if you update to macOS 10.13.2. This should also improve the behaviour for (2) without the need for the beta build below. Users are also reporting that Apple's fix has also fixed (3). This thread is a consolidation of other threads on the forum to try and group this issue, and get feedback in a single place. There have been a handful of users reporting file search issues on macOS 10.13 High Sierra. While this isn't a widespread issue, and I've been unable to reproduce these issues, I am actively trying to get to the bottom of the issues to nip them in the bud. Note: I have also raised some bug reports to Apple to get the underlying issues fixed. 1. Metadata API crash [Rare]: There have been a couple of instances where the Apple metadata API has crashed on its own thread which has caused Alfred to quit unexpectedly. This only happens for specific typed queries or characters into Alfred. It looks like the API is modifying an object after releasing it while collecting results. Workaround: A full reindex of the metadata (using the Rebuild Metadata shortcut in Alfred's Advanced preferences, selecting to delete the /.Spotlight-V100 folder) seems to temporarily resolve the issue. A more robust workaround seems to be clearing out Alfred's Features > Default Results > Search Scope, including unchecking the "Include folders in Home" option, and only adding back the absolutely necessary folders. This may be avoiding files which are upsetting the metadata API. Fix: I'm in the process of moving the metadata querying to an XPC service to run as an Alfred plugin. This means that if the metadata engine crashes, only the plugin will crash (then restart automatically), and Alfred will continue to operate. This essentially downgrades this issue from a crash to "certain typed queries don't return results". I've also reported this to Apple for a proper fix, using the crash logs provided by a couple of Alfred users. 2. Metadata API temporary hang [Rare]: There have been a couple of instances where a call on the Apple metadata API has been temporarily blocked (while possibly waiting on resources). As results are processed on Alfred's event thread, this is causing Alfred to hang temporarily. It seems to manifest more prominently when a Mac has been cold booted, and clear up after a few minutes. Workaround: Same as workaround for (1) above. Also see Fix (with caveat): Fix: I've moved the metadata query to its own sequential operation queue. This means that the results are processed away from Alfred's main thread before being passed back to the main thread. When a hang occurs, this will temporarily block Alfred from receiving further file results until it unblocks, but this won't now stop you from using Alfred. Grab the beta build below to try this out! 3. Metadata matching and result ordering [Infrequent]: This has been reported a little more on the forum, and seems to be an issue with how the Apple Metadata API is returning the default results to Alfred for specific queries. Before 10.13, results were correctly returned to Alfred with the more recent ones first, and this continues to be the case for the majority of users. Once results are within Alfred, Alfred uses his own knowledge to sort the most relevant ones to the top based on your usage. As Alfred only requests a finite number of results, if more recent files aren't being returned by default, naturally, Alfred doesn't show them as he doesn't even know they are matched for the typed query, and this is why users are only seeing these files when a more specific query is typed. Fix: I've updated the way Alfred crafts queries to the metadata API to ensure that the most relevant files are always returned. This should provide an overall improvement to Alfred's default results. Early benchmarks show that this has a negligible effect on file search results performance, but on slower Macs, or Macs with malfunctioning metadata, there may be a small performance hit. Grab the beta build below to try this out! BETA BUILD... Please only take this beta build if you are experiencing these issues, as it's an internal development build, and hasn't been generally tested yet. Note: This build is no longer needed with macOS 10.13.2 which includes bug fixes to their metadata API. Also, please update to the 3.6 pre-release which contains file search behavioural improvements You can go back to the previous build at any point by downloading it from our website. Cheers, Andrew

@-dp- can you pop an email to our info@ address (linking to this thread), and I'll create a workflow for you to try (with alternative file search, and also a workaround). Cheers, Andrew

@mkborregaard this is Alfred's file buffer: https://www.alfredapp.com/help/features/file-search/#file-buffer use alt+backspace to remove all items from the buffer. Cheers, Andrew

@oliver.gierke if the font awesome workflow has a script filter with keyword 'f', it may be started when typing 'f' into Alfred. Other than that, coincidence? who knows Cheers, Andrew [moving to closed]

@bjelakrez Alfred has millions of users, and there are a couple of threads regarding indexing on High Sierra, so this issue isn't common. I have also been unable to reproduce on the three macs I've updated to High Sierra. Every year Apple does a major macOS update, we go through the same rodeo, and it takes a couple of macOS point releases before things settle down again. I am not deserting this issue though, as I mentioned in this thread which you've seen: https://www.alfredforum.com/topic/11000-issue-finding-new-files-based-on-partial-name/?do=findComment&comment=56933 Once I find some workarounds I am happy with, they will be released in an Alfred update. Cheers, Andrew

@oliver.gierke This is the font awesome workflow which has been updated for High Sierra: Note that searching for 'faw' in the forum search found the post above. Cheers, Andrew

@nikivi this is a concept I've been toying with internally for quite some time and I agree, it's extremely useful. It's very likely something similar to this will find its way into Alfred's core in the future! Cheers, Andrew

@dillonplunkett could you pop an email to our info@ address so I can get some more info, and I have a workflow I'd like you to try. Cheers, Andrew

As Vero mentioned, this is a non-reproducible and isolated issue only affecting a handful of users, seems to be specific to certain Macs / Mac configurations, and relates to macOS indexing which is mostly outside of Alfred's control. As an Alfred Powerpack user, there are additional avenues we can take to try to debug this issue on your Mac, provide a workaround which requires workflow features, or allocate more time trying to get to the bottom of your problem. Cheers, Andrew