Way to sort keyword trigger matches before matched Applications (Default Results)?

[luckman212]

- Alfred 4.1 b1205

- macOS 11.0.1

 

I have a few keyword triggers that seem to overlap with names in /Applications (and keywords on certain apps therein).

Example:

 

 

E.g. the example above, ocr is a keyword trigger, and TextSniper is an app that has "ocr" in its Spotlight metadata keywords. I'd like TextSniper to appear at the bottom of the results instead of the top, since 99% of the time I want to action the keyword match, not the app match. Alfred doesn't seem to learn this like it does in other areas—it always puts matching keywords/Apps above keyword trigger matches.

 

Is there a workaround for this? Or may I kindly suggest adding a preference for this?

 

[deanishe]

1 hour ago, luckman212 said:

Alfred doesn't seem to learn this like it does in other areas

 

No. I have a workflow with this same problem. I don't think there's much you can do to move the app to the bottom because Alfred only has a mechanism for moving results up the list.

 

The best solution is probably to change the keyword to something that won’t match anything else, e.g. .ocr (with a leading full stop).

[luckman212]

Thanks @deanishe that's what I was afraid of. Good point about adding the dot prefix, but I'm afraid my muscle memory usually gets the best of me. Here's my vote for a checkbox along the lines of "[X] Prioritize workflow keyword matches above those from default results"

 

Another idea (that would potentially be even better) would be to add a setting to the individual workflow objects that effects this independently per use, e.g.:

 

[Mr Pennyworth]

1 hour ago, deanishe said:

I don't think there's much you can do to move the app to the bottom because Alfred only has a mechanism for moving results up the list.

I guess once something gets strongly latched, it becomes very difficult to unlatch it(?)

So instead of trying to move the app down, let's try simply removing the latching?

 

@luckman212 @deanishe Here's what worked for me:

1. Clear Alfred's knowledge

   ➡  sqlite3 ~/Library/Application\ Support/Alfred/Databases/knowledge.alfdb
   SQLite version 3.28.0 2019-04-16 19:49:53
   Enter ".help" for usage hints.
   sqlite> DELETE FROM latching WHERE keyword == "ocr";
   sqlite> DELETE FROM knowledge WHERE keyword == "ocr";

    

2. Type "ocr" in Alfred, press "⌘-2" (to select "select screen area"). Now on, after typing "ocr", "select screen area" is the first result, not "TextSniper.app"

 

Note that this doesn't really do exactly what @luckman212 asked, it just effectively pushed the app down by one, and moved "select screen area" up to the top. To push the app all the way down (after clearing the latching and knowledge rows), you gotta repeat step 2 above for all the options in your list filter

Edited December 11, 2020 by Mr Pennyworth

[Mr Pennyworth]

3 hours ago, luckman212 said:

Alfred doesn't seem to learn this like it does in other areas—it always puts matching keywords/Apps above keyword trigger matches.

Looking at the "knowledge" and "latching" databases, this doesn't seem to be the case. Alfred always keeps learning...

 

What is not immediately clear from the DBs is how any particular latching becomes "strong" and stops being "strong".
@Andrew is this part of Alfred's secret-sauce or is it something you don't mind shedding more light on?

[deanishe]

2 hours ago, Mr Pennyworth said:

I guess once something gets strongly latched, it becomes very difficult to unlatch it(?)

 

It's fairly quick to retrain Alfred, but that's not the issue. The problem is that if Alfred thinks something is a good match, there's no way to tell it it isn't. All you can do is try to train Alfred to move all the other items up instead, which doesn't work very well.

 

[luckman212]

@Mr Pennyworth Thanks but this isn't about Alfred's knowledge/latching. It's simply that Alfred currently puts matching applications above all other results, regardless of their implied or learned order.

[deanishe]

Just now, luckman212 said:

Alfred currently puts matching applications above all other results, regardless of their implied or learned order.

 

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.

[Mr Pennyworth]

6 minutes ago, luckman212 said:

@Mr Pennyworth Thanks but this isn't about Alfred's knowledge/latching. It's simply that Alfred currently puts matching applications above all other results, regardless of their implied or learned order.

This is a claim that could be experimentally verified, no?

 

This is the list filter I used for the experiment:

 

After running those two SQL queries, and following step (1) and (2) from my previous answer, here's what I get:

@luckman212 are you certain that on your machine (both our builds are same 1205)
Alfred *always* ranks app results above list filter results?

Did you delete those "ocr" related DB rows, then follow (2) and still end up with textsniper.app ranking above your list filter results?

That sounds like a very strange bug to me...

[luckman212]

@Mr Pennyworth Hmm, to be honest no, I didn't verify that. It's just that I rarely use TextSniper, and I use the "ocr" keyword quite a lot, so I assumed if Alfred was ranking TextSniper higher, then it must highly (or exclusively) prioritize App results over workflow results. I'll do a few more tests and poke at the sqlite3 db as you suggested.

[Mr Pennyworth]

1 minute ago, luckman212 said:

and I use the "ocr" keyword quite a lot

@luckman212 Good point!
There's a caveat though: If you want to tell Alfred to rank "select screen area" above "TextSnip.app" when you type "ocr" (just the keyword, and no extra argument) the only way to do that is "cmd+2" after "ocr" (without any extra argument) (as opposed to typing additional letters, getting "select screen area" to top, and then pressing enter)

 

I'm not saying you don't know this already.
You probably know this, or this might be new; I can't be certain either way.
So, for clarity and written reference, here goes:

 

A user might type "ocr s", get "select screen area" as first option, and press enter.
The user might do that again and again and again, say, 100 times.
It would surely create a feeling that the user is using the keyword "ocr" a lot, and hence, training Alfred to go for "select screen area" for "ocr". But technically, all that training gets superseded (as far as just "ocr" is concerned) by a single instance of the following:

1. user types "ocr" (without space or arguments)
2. assume, "TextSnip.app" is the 4th result
3. presses cmd+4
4. TextSnip.app is launched

now on, when the user types "ocr" (without space or arguments), TextSnip.app ranks at the top.

For exact keywords, entries in latching table outrank entries in the knowledge table
Hence one usage of "ocr" -> "TextSnip.app" outranks hundreds of usages of "ocr se" -> "select screen area"

@luckman212, out of curiosity, when you said you use the "ocr" keyword a lot, did you mean

1. the exact letters "ocr", followed by ⌘+<number> to choose from results
   OR
2. "ocr" followed by an optional space, and then some letter, so that the desired result comes to top, then press enter?

[luckman212]

@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>

[Mr Pennyworth]

11 minutes ago, luckman212 said:

No effect, TextSniper.app is still ranked in the #1 spot even after 30-40 rounds of banging on my keyboard.

Ouch.
Sorry for the useless instructions!
Seems like a headscratcher! Would've been fun to debug, but can't reproduce the buggy behavior

 

3 hours ago, Mr Pennyworth said:

What is not immediately clear from the DBs is how any particular latching becomes "strong" and stops being "strong".
@Andrew is this part of Alfred's secret-sauce or is it something you don't mind shedding more light on?

Shouldn't have asked Andrew to chime in for such a simple thing!
Turns out, latching starts out with "strong" == 0 and one more invocation makes "strong" == 1 and it remains that way.
If a competing latching is about to occur, if strong is 1, it simply becomes 0 and the competing latching doesn't materialize.
Seems like a cool way of being forgiving for one-off mistakes when made infrequently!

[Andrew]

13 hours ago, Mr Pennyworth said:

If a competing latching is about to occur, if strong is 1, it simply becomes 0 and the competing latching doesn't materialize.
Seems like a cool way of being forgiving for one-off mistakes when made infrequently!

 

Yep, you've nailed it - this is how the latching works, and allows for quick re-latching if you select it a few more times regardless of how often items have been used.

 

@luckman212 do you have latching enabled in Alfred's Advanced > Learning? It should be by default.

 

There are a few complications and caveats to the ranking and latching, and in actual fact, this is an area intend to internally simplify and improve, as Alfred has grown at a faster than the ranking algorithm, and I want to maintain the original ethos of Alfred's accurate result presentation.

 

@Mr Pennyworth's research on to this is pretty accurate, if you select a keyword to make it unique for the typed phrase, for example, for ocr, you could type "o", then scroll down to ocr and press return to pre-"action" it and make it unique in Alfred's results. If you do that a few times, it should strongly latch to "o".  Remember that the latching is based on what you've typed, and separate to the knowledge, so you can latch different things for "o", "oc" and "ocr".

 

Cheers,

Andrew

[luckman212]

@Andrew Thanks for this explanation (Yes I do have latching enabled btw).

 

I see I can get Alfred to put the "ocr" keyword (which is a simple list filter) result at the top if I action it a few times on "oc" - as you said. But, the list items don't appear until I hit <Enter> on the list filter's entry point.

 

If I then execute the workflow, wait a couple of seconds and then hit my Alfred hotkey again, the word "ocr" is there and TextSniper.app is once again at the very top.

 

So again, it seems like when there's an exact keyword match on an Application's Spotlight kMDItemKeywords, Alfred prioritizes it above all others. Not sure if that's intentional, a bug, or just a shortcoming.

 

[Mr Pennyworth]

47 minutes ago, luckman212 said:

Not sure if that's intentional, a bug, or just a shortcoming.

Sounds like a bug to me.
Not because the way it behaves, but because the way it inconsistently behaves.

 

This what's happening with @luckman212:

17 hours ago, luckman212 said:

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.

 

This is what's happening with me:

• Start with deleting all "ocr" related rows from both "knowledge" and "latching" tables
• TextSniper.app shows at top
• Type "ocr" an then ⌘2 to latch something other than the text sniper app
• Now on, text sniper app is no longer at the top when typed "ocr"

 

Both of us are on build# 1205
I'm on Catalina
@luckman212 is on BigSur

 

Going by luckman212's report there seem to be two possibilities: on their machine:

• either the row in latching table is not being created/updated (even after many ⌘2's) (SQlite connection / adapter bug?)
  • What about the knowledge table, you ask?
    -> it shouldn't matter because both of us have cleared it before the experiment
• or Alfred's behavior somehow diverges between Catalina and BigSur
• or, of course, a third thing that I completely missed 😝

@Andrew @deanishe do you guys think it makes more sense to move this to "bugs" category?

[Andrew]

@luckman212 can you try something for me, set your ocr workflow to Argument Required. This way, the list filter's contents (results) won't be shown when you type 'ocr'. Then type 'ocr' and select the OCR placeholder and press return, this will make it unique. Do this a couple of times, then tell me if it's at the top?

 

I'm guessing that with "Argument Optional", you're never actually able to latch the ocr keyword to the List Filter object, only its containing results.

 

While this isn't a bug per-se, I do feel like this needs improvement within Alfred.

[luckman212]

@Andrew Right, ok, so when I set the list filter to Argument Required, then after a few times hitting <enter> on it (which does nothing)... yes the workflow now surfaces to the top...

 

but to get to any of the list filter items, of course I have to put a space ("ocr ")...

 

Agree that this doesn't really feel like a "bug" since I understand that list/script filter results don't get individually latched, but if you're open to considering making any changes to this behavior, may I suggest something along the lines of my comment above? (whereby the list object can specify that its results should be prioritized over other results).

 

I don't know how difficult that would be under the hood of course...

[Andrew]

@luckman212 I'll keep this thread in mind when re-looking at the knowledge / sorting, as there are a couple of things for consideration. One is users generally wanting workflows above apps - I've actually played with this before, and it wasn't the panacea I thought it would be as it caught me out more than not. Another possible thing could be pinning certain results to the top, but this could end up being quite complicated to configure as it would have to be based on typed phrase otherwise the results would become saturated with the pinned items.

 

In the example you present here, the combination of Argument Optional and a specific conflicting keyword makes it impossible to latch the parent placeholder. This is because, in your case, when you type ocr, the placeholder matching the keyword 'ocr' is gone and replaced by the list filter's results, so you never get the opportunity to select the placeholder while 'ocr' is typed.

 

The best option, as mentioned before, is to use a different keyword. Another option could be to add TextSniper to the macOS Spotlight Ignore, then add a simple workflow with Key -> Launch App to replace that item in Alfred's results.

 

Another option is to type 'o' and latch this for your workflow list filter, then you can type o[return] to make the list filter results unique.

[luckman212]

Thank you again @Andrew for taking your time to look at this probably quite uncommon edge case! (and thanks to @Mr Pennyworth and @deanishe too)

 

I stubbornly did not want to change my keyword trigger or add a full-stop to it. In the end I settled on this workaround, based on some good suggestions in this thread:

 

1. I added Alfred:ignore (just learned about this trick!) to TextSniper's Finder comments, which causes it to be excluded it from Alfred's default results:

 

2. I inserted a 'textsniper' entry at the bottom of the ocr List Filter and wired it up to a Launch Apps action, along with a generic keyword so I can still type TextSniper in Alfred and launch it, if desired:

 

results:

 

 

 

 

For now this works fine, but of course is a bit convoluted and gets rather unwieldy as the number of edge cases grow.

 

[vitor]

I’ve been following this one attentively. This is also something I bump into, and my particular wish would be for Script Filters which just show updating information and aren’t actionable (valid:false) to be easily latchable.

Tangentially, before I spend the time researching, does anyone have a preferred method to ignore stuff from Alfred via the command line? Be it the equivalent to adding to Spotlight’s Privacy panel or adding alfred:ignore as a comment, or something else.

[Mr Pennyworth]

5 hours ago, vitor said:

Tangentially, before I spend the time researching, does anyone have a preferred method to ignore stuff from Alfred via the command line? Be it the equivalent to adding to Spotlight’s Privacy panel or adding alfred:ignore as a comment, or something else.

@vitor I use this command:

# A file action (that allows multiple files)
# The file action writes the files to /tmp/alfred-ignorelist, then calls the script

cat /tmp/alfred-ignorelist | /usr/local/opt/findutils/libexec/gnubin/xargs -d'\n' -i -n1 osascript -e 'on run {f, c}' -e 'tell app "Finder" to set comment of (POSIX file f as alias) to c' -e end "{}" "alfred:ignore"

rm /tmp/alfred-ignorelist

# for recursively ignoring everything inside a folder
find -L /path/to/folder | /usr/local/opt/findutils/libexec/gnubin/xargs -d'\n' -i -n1 osascript -e 'on run {f, c}' -e 'tell app "Finder" to set comment of (POSIX file f as alias) to c' -e end "{}" "alfred:ignore"

 

Edited December 14, 2020 by Mr Pennyworth

[luckman212]

@vitor I'm currently playing with osxmetadata and it's pretty robust. It's Python, so fits nicely within an Alfred workflow, and can be imported as a library within an existing Python script / script filter, or run directly as a CLI from the shell. Besides Finder Comments, it can manipulate other types of metadata too, like tags, keywords, etc. It also supports JSON output, which is always nice.

 

One way to install...

brew install pipx
pipx ensurepath
pipx install osxmetadata

 

If you have virtualenv set up, you can do it that way too (probably better)

mkvirtualenv osxmetadata
pip install osxmetadata
ln -s $(which osxmetadata) /usr/local/bin
deactivate

 

To use...

osxmetadata --set findercomment "This is a comment" /path/to/file
osxmetadata --get findercomment --json /path/to/file

 

Edited December 14, 2020 by luckman212

[Andrew]

13 hours ago, vitor said:

I’ve been following this one attentively. This is also something I bump into, and my particular wish would be for Script Filters which just show updating information and aren’t actionable (valid:false) to be easily latchable.

 

I'll add this to my list, but am aware that it may also cause some undesirable behaviour... for example, if a user doesn't want a valid:false item to ever have any significance, and all of a sudden it's been promoted to the top, this isn't good.

 

It's likely if this is added, there may be a different valid: state which could be treated differently.

[Mr Pennyworth]

1 hour ago, Andrew said:

there may be a different valid: state which could be treated differently.

By "result" I mean "item" in the following.
I'm not sure what's the correct term 😝

 

"everything is a result" is an interesting philosophy.
Reminds me of "everything is a file" philosophy of Unix.
The universality brings simplicity and elegance too, no doubt!

 

However, the discussion of a third "valid:" state made me wonder...
(consideration of complexity and elegance aside)

• What if everything is not a result?
• If a result isn't valid, is it really a result? After all, nothing could be done with it.
• Alfred already has specialized UIs, they are just not exposed to the workflows:
  • Snippet and Clipboard History Viewer
  • Mini Music Player
  • The tiny "update available" notice
• What if Alfred exposed more UI elements for workflow authors? Given how elegantly crafted the whole workflow editor is, there's no doubt @Andrew could make a few well-designed, judiciously-crafted UI elements that fit into Alfred beautifully.

To my naive eye, it looks like Alfred could benefit from a "notice" element.
The notice could be used as

• a status indicator
• a progress monitor
• an error flag

Someone could even go ahead and build a breadcrumbs UI using the notice.
(would be cool for multi-level-menus (I gather @deanishe would love better support for building multi-level-menus))

 

An example from Raycast (By a "notice element", I mean something like "Clipboard History" at the top left):

I understand that it's possible that this could be a stretch.
Also, it could be seen as "beginning of cluttering of UI".

 

It's just that I keep having this feeling that "valid: false" results don't belong with the main results, philosophically.
So throwing this out here for discussion

Edited December 14, 2020 by Mr Pennyworth