Andrew

@deanishe no timescale yet, as I'm still adding stuff... possibly within a week or two though!

@bertg there is no way of Alfred knowing if this behaviour has been overridden (other than if you are doing it directly within Alfred with a workflow). From High Sierra and onwards, trying to type this combo to set as a hotkey in Alfred will be intercepted by macOS and your Mac locked, so this will prevent people from accidentally setting this combo. It's likely that this combo was set on your Mac before High Sierra? As for finding what is launching this - check your Alfred workflows for a hotkey linked to a launch app. Do you also have any other keyboard or automation related 3rd party apps installed you can check? It's unlikely that I'll be changing dispatching this combo back to the old behaviour, as the pre-10.13 way of locking now causes macOS High Sierra to hang.

@lemikeone are you experiencing this with any other images from other sources? Alfred asks the clipboard if there is data of type NSTIFFPboardType, then creates an NSImage image out of this data. I'm wondering if Snagit is providing multiple data types, but incorrectly populating the NSTIFFPboardType. Cheers, Andrew

This is now fixed in the 3.6.1 pre-release. I've newly written Alfred's CSV parser to adhere to RFC 4180, and will create a document page to cover how Alfred deals with the ambiguities surrounding quoted lines with significant leading spaces. Essentially, for a line to be quoted (allowing for newlines and commas), the " needs to be either at the very beginning of a line, or directly after a comma. If there are spaces after a comma then a ", this field is not treated as quoted, and any " marks are treated as literal. I spent some time looking at how some of the online CSV parsers (differently) dealt with this specific ambiguity, and felt that this way best covered all bases As mentioned earlier, Alfred's CSV parser never discards significant spaces, but the List Filter subsequently trims the title and subtitle fields. Cheers, Andrew

This is now fixed in the 3.6.1 pre-release.

This is now fixed in the 3.6.1 pre-release.

This is now fixed in the 3.6.1 pre-release.

@deanishe This is now fixed in the 3.6.1 pre-release

@s4nji sorry for the slow reply on this. I've now re-written Alfred's CSV parser so this should now work as expected in the 3.6.1 pre-release. Let me know how you get on! Cheers, Andrew

@vitor Alfred will still be trimming certain stuff after importing regardless of the CSV, such as the title and subtitle (because that makes sense, and Alfred generally trims where sensible), but the arg would not be trimmed as that's more significant.

I'm currently updating Alfred's CSV importer to adhere to RFC 4180 which is pretty well summarised on wikipedia: https://en.wikipedia.org/wiki/Comma-separated_values What's interesting is that in @vitor's original post here, he added spaces around the fields which are supposed to be significant (and likely will be in Alfred's updated CSV importer). In that wiki page, it says that some importers trim fields, and where spaces are significant, the fields should be quoted. I feel this may suit Alfred's purpose better, but then this deviates from the RFC 4180 spec. Any thoughts? Cheers, Andrew

@bertg From Alfred 3.6, the lock command simulates ⌃⌘Q to lock your Mac with High Sierra installed (the new macOS system wide shortcut). If you have Alfred (or another app) overriding this key combination to launch Sequel Pro, then when Alfred dispatches this combination to macOS assuming it will lock your Mac, the combo will be intercepted and diverted to whatever is overriding it. I suspect this will be what is causing the unexpected behaviour in your case Cheers, Andrew

@Tsunami thanks again, nicely spotted

Sorry about the slow reply on this. I've now had a chance to look into what is happening. Alfred is using NSRegularExpression which treats \ in the replacement template string as a literal, and it looks like it's just being stripped in the replacement. See Table 3 here: https://developer.apple.com/documentation/foundation/nsregularexpression?language=objc If you were to actually put a new line in the replacement (i.e. instead of using \n, use alt+return), then it works as expected. Cheers, Andrew

@Tsunami thanks, I'll get this fixed in the next release. I'd forgotten to connect that button up to the editor text view, so while it was "working", it didn't know where to insert the text Cheers, Andrew

Well spotted! I'll get this fixed in the next release Cheers, Andrew

@vermeer Adding to what @Vero said, I tried to reproduce this and cannot get a scenario where a snippet collection isn't selected automatically in the save dialog. Is there anything specific you are doing to cause this, as I'll need to fix that. Cheers, Andrew

@RueiShuYe can you navigate into other folders ok, or are you just having problems within /Library/? If it's only some folders, open Console.app and see if there are any errors when you try to navigate into these folders. Cheers, Andrew

@chill snippet triggers were added in Alfred 3.4 https://www.alfredapp.com/help/workflows/triggers/snippet/ As for regex matching of snippet keywords, this isn't available. Cheers, Andrew

@AmeliaMN If you haven't changed Alfred from the default focus mode, then the underlying app shouldn't loose focus when showing Alfred. Having said that, I think TweetDeck may be written in a non-native cross-platform type toolkit / runtime... so the behaviour may not be standard macOS. Have you restarted your Mac recently? If not, this may kick the focus behaviour in TweetDeck back to normal. As a work around, I believe the emoji pack has been correctly implement such that in this case, you can copy the emoji manually instead of pressing return to select the emoji. Then you can manually cmd+p to paste it where you need it. Cheers, Andrew

@Srisri this crash looks to be caused by the macOS' spell checking engine. Alfred's preferences doesn't directly use this, only implicitly through the the of macOS standard text fields. One thing you could try is open the macOS Dictionary app preferences, and remove all dictionaries, then re-add them? Or perhaps try re-adding a different one to see if the main dictionary is corrupt. You could also try temporarily creating a new user account, switching to that user and see if you experience the issue there. There could be something corrupt on your main user account. Cheers, Andrew

@ulysse This is caused by an Apple metadata API bug in 10.13. I raised this with them and they fixed it in macOS 10.13.2. If you update to the latest macOS (10.13.3), then this issue will be fixed. Cheers, Andrew

@FroZen_X no timeframe yet, as this change will be wrapped up with some other similar ones to consolidate some code. Remember that you can wildcard in that view too. The original behaviour in the navigation was based more on shell which is why it deviates. This is now a bit outdated as Alfred has grown which is why it's going to get an overhaul to bring it more in line.

@Avijeet Prasad In actual fact, for 3.6.1, I've made an addition to the Dispatch Key Combo input field which allows you to edit the modifiers from the [right click] popup menu. This will allow you to set combos which are otherwise reserved and intercepted by macOS. In your example, you'll be able to enter 3 into Alfred's key combo box, then on the popup menu, select shift and command as the modifiers. 3.6.1 is currently in development, so this will be available in the next update Cheers, Andrew

Alfred's window opens when you select the preferences? or do you mean the Alfred Preferences window opens? Also, does Alfred crash, or the preferences crash? (they are two separate apps). Are there any crash logs in Console.app's User Reports section? Crashes are unusual for Alfred, so it could be a corrupted app package - Have you tried re-downloading Alfred from the dmg on our website?