Andrew

@deanishe is correct, Alfred places plain text in the clipboard. This is something you'll have to take up with Spark, and will be reproducible outside of Alfred if you copy from a plain text app.

With 8 years of experience helping our Alfred users daily, I can say that this isn't always true. A very likely scenario is that a user will blindly select "unlimited", even though they don't need it, ignore the implications warning, then start complaining about Alfred appearing in Apple's "Significant Energy" menu. As I said, I will very likely add in a longer expiry, but not as a trivial "turn up the volume".

It's likely that in the future, the maximum persistence time for clipboard history will be increased. Without going deeply into the architectural details, the reason this isn't a simple "turn up the volume to unlimited" type change is because there is are significant performance considerations. It doesn't matter if setting the maximum clipboard history makes searching the clipboard history slower, this is, after all, the user's prerogative. The fundamental issue is more about maintaining an extremely large full text index on inserting new text data every single time you cmd+c, leading to higher idle CPU usage (and potentially lower battery life). Alfred is intrinsically extremely lightweight, so before providing a longer clipboard history, a number of architectural changes would have to happen. For example, one solution could be to automatically archive data every week into a different "long term" store. This would allow Alfred's day to day usage to be extremely fast and low resource use, while providing access to those "every so often" needed items you copied 2 years ago. To be clear on timescales, any architectural change won't happen on a maintenance release - but rest assured that this feature request is on my radar. Cheers, Andrew

@rab523 which folder have you set Alfred's preferences to? If you are using iCloud, it could be Apple's Optimised Storage causing an issue: https://support.apple.com/en-us/HT207236 We recommend using Dropbox as in our experience, it's the most reliable file based syncing service. Cheers, Andrew

@bruceweinstein When setting the preferences folder location, Alfred uses this folder in real time, so as long as Dropbox is syncing, the preferences will be synced. The actual .alfredpreferences file is a package containing many separate files, so the date on the top level package doesn't change.

@avclark In that screenshot, you have the script type set as bash, and the script you've entered is (mostly) AppleScript. Bash will probably be throwing errors for each line other than: osascript ~/scripts/ht.applescript ...and this one you haven't passed any arguments to.

@shadylane while Alfred's clipboard history is stuck on the screen, could you open Activity Monitor, select Alfred 3 then select View > Sample Process from the menu bar. Pop this in an email to our info@ address and I'll take a look - it could give a better clue as to what is blocking Alfred! Cheers, Andrew

@Hincin Unfortunately, there is no way for Alfred to know the underlying behaviour of Xcode... the snippet is 2 characters long, which is the equivalent of pressing backspace twice. When I do this manually in Xcode (as you've recognised), this deletes [] on the first backspace, then the character before it on the second, before inserting the snippet. The only workaround is to use a keyword which doesn't get manipulated by Xcode, or if there is a way to turn off certain auto-replacements in Xcode, turn them off for your relevant matching snippet keywords. Cheers, Andrew

This is now in the b901 pre-release. I've been meaning to add this for quite some time!

@Chardy Alfred keeps snippets as individual files in the Alfred.alfredpreferences package snippets folder. The snippets.alfdb is rebuilt from the snippet files for fast efficient search. The files you'd need to recover would be the Alfred.alfredpreferences/snippets/[snippet collection]/. Unfortunately, if you don't keep a backup of this, I'm not sure what your options are :/

If you're a Powerpack user, could you fill in your Powerpack address as there are better ways to filter using Workflows which I can describe. As a non Powerpack user, your only option is to add the location of the Outlook emails to Alfred's Default Results > Search Scope, then untick Features > File Search > Search > Don't Show > Emails. I'm not sure the exact location of Outlook's folders, but a quick search on Google reveals that it will be something similar to: ~/Library/Group Containers/UBF8T346G9.Office/Outlook/Outlook 15 Profiles/Main Profile This may allow emails to be shown in your default results, but as I don't have Outlook, I can't verify this. I'd generally recommend against adding emails to Alfred's default results, as this will make the file search significantly less useful, which is why using a Workflow is better, it can keep the email results separate. Cheers, Andrew

@snoblenet Is it a workflow you're using for the "Search in Spotlight" fallback (it's not a default Alfred fallback). If so, my guess is that this workflow is simulating a hotkey to show Spotlight, then simulating typing to populate it. It could be that there is a conflict between the Alfred hotkey and the simulated hotkey it's using. Vheers, Andrew

@deanishe this is now available in the fs navigation view in 3.6 b900, either click the button bottom right of the window or use cmd+shift+i

@woowoo the minimum size is 400 as smaller than this is unusable with some of the sub views. Is there a specific reason you need less than 400px?

The main reason I avoid full fuzzy in the rest of Alfred is performance and result noise, but I agree with what's said here. I'll look at improving this!

@deanishe agreed, this preview should be able to be turned off. Also, the fuzzy matching option for fs navigation isn't working as well as it should do. When @FroZen_X posted the request the other day, I took a look at the matching code... really, with fuzzy enabled, you should just be able to type e.g. fixum and it filter to just that item (instead of *fixum).

@Alex007 try temporarily switching to Safari to see if this is a Chrome issue or macOS issue. Cheers, Andrew

Right, I've been toying with this for the past 4 hours, and how to architecturally fit this into workflows, and it's grown outside of the scope of what I want to add last minute for 3.6 which is already in pre-release. I'm going to look at some more holistic changes which can incorporate the two things above.

@deanishe yep, the keyword would be added automatically.

@deanishe You are correct that the external trigger history is excluded due to the potential mid-processing statefulness. Alfred essentially has 3 states in the default results: Straight up typing stuff in Same as 1 but filtered to a single input (this is i.e. if you were to press return on an input which requires an argument, Alfred only shows results from this input) Direct input via an external trigger (Alfred shows the icon on the right hand side) Options 1 and 2 above are included in Alfred's history, option 3 is not. One potential solution to this is having a new option which makes an input behave in mode 2 instead of mode 3 when being shown as a result of an inbound connection. This would allow you to switch to using the "run trigger" AppleScript instead of "search" AppleScript, get the benefit of Alfred's history while also ensuring that you only see the results you intend the user to see (i.e. if there are multiple matching keywords which would break your current method). This way, you wouldn't need to know the keyword (plus "with space" state if you need to reconstruct a valid search string).

Thanks for bringing this back up, I've had a ticket for to somehow pass the typed argument out of inputs as a variable for quite some time (but got lost down the queue). I'll have a think about this before 3.6 is generally released. @deanishe I've still to be convinced how useful having access to the keyword used to call the action. If you're using to to show Alfred again with the same keyword (AppleScript), this could give quirky behaviour as the keyword is user editable and multiple inputs can have the same keyword. If you give me a solid use-case, I'll have a think about what I can offer to give a solid solution for what you're looking for. Cheers, Andrew

@buckreynolds this could be an indication of a corrupt clipboard database, or the clipboard database on a slow access drive. Is there anything unusual about your Home folder / Application Support folder? (i.e. stored on a network or external device?). When was the last time you restarted your Mac? Alfred attempts to clean the clipboard database when launching. One option could be to set your clipboard history to a shorter period (e.g. 1 month), as if for some reason access is slow, a smaller db will make it faster. Note that you can speed up Alfred's trimming of the db after making this change by restarting Alfred. Cheers, Andrew

@natebeaty thanks for the update

@Steve Ball try temporarily setting your default browser to Safari (in Safari's preferences) to see if the problem lies at the macOS level, or just Chrome. Cheers, Andrew

@shadylane This sounds peculiar, and possibly indicates that Alfred is struggling to access the clipboard database. This could be one of a couple of things, firstly, it could be that the hard drive is asleep, OR it could be that the clipboard database has become corrupt. Could you try rebuilding this db by clearing the clipboard history from the preferences > features > clipboard > clear now button. Let me know how you get on! Cheers, Andrew