Mr Pennyworth

Kind of, but it's not obvious. If you right-click on your Keyword or Script Filter, choose Inbound Configuration and set Inbound Mode to "Keyword" (and give your Keyword/Script Filter a keyword), your workflow will open in "normal" mode (keyword + query) even when you use a Hotkey. Then Alfred will remember your queries in its history.
 
If you don’t want the keyword showing up in normal results, put a punctuation mark at the beginning (e.g. :devon)

This is very interesting behaviour from iMessage, and it doesn't surprise me, as iMessage is quirky in quite a few different ways.
 
While this isn't a "quick fix" in Alfred, as he currently singles out specific types, and doesn't store broad data in the history, one workaround is to turn off storing files in Alfred's clipboard history (if you're not using them often). For various reasons, Alfred prioritises files above images in the history check, so disabling files will get the image correctly from iMessages.
 
In the further future, it's very likely that Alfred will have a more broad and intelligent clipboard history which will be able to work with this kind of issue.

Thanks for the feedback, I'll be sure to allow for the old (or better) behaviour back.
 
It's worth adding, one other reason I changed the default behaviour was because you had this awkward look with rounded corners:
 

 
But you're right, vanity should definitely not take precedence over function.

I found the old scrollbar behavior very helpful. It immediately told me that there are more results and not just the 9. From a UX perspective, I think the macOS behavior to "show scrollbar only while scrolling" isn't exactly the same Alfred's latest choice. In most places (like a browser for example), there are plenty other visual affordances to let you know that "there is more content". For example, looking at a webpage, or an article, it becomes apparent most of the times that there's more stuff below the fold. In contrast, the scrollbar was the sole indicator of it in Alfred.
 
So, here's another strong vote in favor of "I really really wish Alfred gave me a choice to restore old behavior"

I am happy to change the Terminal Action to not trim.
 
 
uhhh what is BOMs? *google search*
 
 
Ah yeah cool, I'll keep trimming these...

As of v4.1 this works:

More like I was imagining their platform might be used to provide search-as-you-type for other websites... beyond Google.

Thanks @Alfred0!
 
My most favorite use-case is actually something that I hadn't originally thought about:
"Search Google as You Type"
 
Google has become more and more of a question-answering-machine.
So many times, I just want a quick answer and am not looking at reading articles/blogs etc.
For those cases, the mode of operation is "search google -> look at result -> move on".
 
The extra pane fits so well for them!
And ofc, pressing enter would open the same page in browser if I want to interact with that page further.

@Andrew The above involved writing this script filter:

I would agree that writing such a script filter is a minimal-effort, no-hassle thing.
It does feel like a teeny-tiny duplication-of-function though, given that Alfred already has awesome web-searches.
Is there a way to access the URL the web-searches are building?
Or, would it be possible to expose those URLs through press-secretary?
Or, is that not desirable due to privacy concerns?
 
Also, is there a programmatic way of accessing the web-searches? cc: @deanishe @vitor
(that way, someone could programmatically build a workflow mirroring the web-searches and their keywords if they want)
I scoured through various plists and alfdbs, but couldn't find where they are stored...
Are they stored in some proprietary format / right inside the binary?
Or did I miss something obvious?
 
Having said all this, I must agree I don't really foresee much value in doing this for all web-searches because with the exception of google and wolframalpha, I would assume most of the searches are such that they require further interactions with results (like clicking a link, copying some text etc).
 
Aside:
Here's a different (vertical) configuration I've been toying with:

 

Thanks @Alfred0!
 
My most favorite use-case is actually something that I hadn't originally thought about:
"Search Google as You Type"
 
Google has become more and more of a question-answering-machine.
So many times, I just want a quick answer and am not looking at reading articles/blogs etc.
For those cases, the mode of operation is "search google -> look at result -> move on".
 
The extra pane fits so well for them!
And ofc, pressing enter would open the same page in browser if I want to interact with that page further.

@Andrew The above involved writing this script filter:

I would agree that writing such a script filter is a minimal-effort, no-hassle thing.
It does feel like a teeny-tiny duplication-of-function though, given that Alfred already has awesome web-searches.
Is there a way to access the URL the web-searches are building?
Or, would it be possible to expose those URLs through press-secretary?
Or, is that not desirable due to privacy concerns?
 
Also, is there a programmatic way of accessing the web-searches? cc: @deanishe @vitor
(that way, someone could programmatically build a workflow mirroring the web-searches and their keywords if they want)
I scoured through various plists and alfdbs, but couldn't find where they are stored...
Are they stored in some proprietary format / right inside the binary?
Or did I miss something obvious?
 
Having said all this, I must agree I don't really foresee much value in doing this for all web-searches because with the exception of google and wolframalpha, I would assume most of the searches are such that they require further interactions with results (like clicking a link, copying some text etc).
 
Aside:
Here's a different (vertical) configuration I've been toying with:

 

@evanfuchs aha! got it!
That's such a bad bug!!
Thanks so much for reporting it
I fixed it in v0.0.5, download it and give it a go

Sure, sorry about that. The workflow is working as expected, but I am finding an unexpected issue the Clipboard History Viewer related to the workflow.
 
The typical behavior after triggering the Clipboard History Viewer (for example, using the keyword clipboard), is that RETURN will paste the selected item into the foreground app, while COMMAND-C will copy that item back to the clipboard so you can paste it elsewhere without automatically pasting into the foreground app.
 
After installing and running this workflow, COMMAND-C puts /Users/<username>/Library/Caches/com.runningwithcrayons.Alfred/Workflow Data/mr.pennyworth.gif/selected.gif on the clipboard.
 
If I run killall AlfredGifBrowser, the issue with Clipboard History Viewer goes away.
 
I hope I'm explaining it clearly.
 
 

@Mr Pennyworth I just nuked my entire knowledge db to test this, and tried a few rounds of typing "ocr" followed by ⌘2. No effect, TextSniper.app is still ranked in the #1 spot even after 30-40 rounds of banging on my keyboard.
 
To answer your question, the way I use the ocr keyword is, typing the exact phrase "ocr" followed by hitting <ENTER> (it was previously the first item in the results). After installing TextSniper, I now type "ocr" followed by the ↓down arrow key and then <ENTER>

If you've trained it to, Alfred will show a workflow keyword above an application.
 
A workflow's keyword is not the same thing as the items the workflow emits, however. If you want "select screen area" etc. items to be above TextSniper, you'll have to train Alfred to move each one upwards.
 
Or use a different keyword. Or use oc↩ to "enter" your workflow, so Alfred only shows results from the workflow.

Deleting a bunch of code is so satisfying!
no more mouse tracking no more keypress monitoring no more accessibility hoops to get window events and sizes no more guessing "how does Alfred rank results?"

Deleting a bunch of code is so satisfying!
no more mouse tracking no more keypress monitoring no more accessibility hoops to get window events and sizes no more guessing "how does Alfred rank results?"

Deleting a bunch of code is so satisfying!
no more mouse tracking no more keypress monitoring no more accessibility hoops to get window events and sizes no more guessing "how does Alfred rank results?"

Deleting a bunch of code is so satisfying!
no more mouse tracking no more keypress monitoring no more accessibility hoops to get window events and sizes no more guessing "how does Alfred rank results?"

Deleting a bunch of code is so satisfying!
no more mouse tracking no more keypress monitoring no more accessibility hoops to get window events and sizes no more guessing "how does Alfred rank results?"

@Mr Pennyworth could you please update to pre-release b1203 which will fix this spelling mistake, and also make the notifications fire on relevant mouse movement.

@Mr Pennyworth ....
 

Typo alert: "annoucement" is missing an "n"

Which Alfred isn’t. There’s a huge difference between adding OAuth integration to your app, and adding OAuth integration to other apps from yours.

And the differences don’t stop there. Linear is by a company who just raised millions in venture capital and will sell itself (and its users) to the highest bidder they can get (because that’s the goal of raising that money). Alfred is by an independent company with a single developer who has to choose wisely which features to spend time on, and a high work low usage feature isn’t a wise investment.

These aren’t comparable. Linear just got a bunch of money (and thus resources) to throw away on rapid expansion and buzzworthy features. They can afford to hire developers who will spend their time implementing OAuth while burning out questioning their life choices and wondering why they didn’t get into carpentry instead.

These aren’t comparable. “App adds OAuth” doesn’t prove in any way that it’s a good idea for everyone. If tech trends were to be followed blindly, Alfred would be an Electron app with integrated chat and its own emojis.

@Mr Pennyworth Ah sorry about that - I'll get that added for the next pre-release build (which likely won't be until tomorrow now).
 
Cheers,
Andrew

@Mr Pennyworth If you update to b1201, you should get more satisfying results.
 
I now use NSStringFromRect for the window rectangle, so you should be able to use NSRectFromString to convert back.
 
Cheers,
Andrew

@Mr Pennyworth hah very strange, it seems that it doesn't like the NSValue version of NSRect and discards that message (I was only doing internal logging of messages sent so didn't see they weren't being delivered).
 
Give me 15 mins, I'll see what I can do.