Remembering query text in script filter rerun (or query history)

[h2ner]

Hello,

 

In my current in progress script, I might use a script filter to query some data, act on some result, and then wish to return to the same filter and pre-fill the previous query string, either to look at other results, or refine the query. I haven't yet tried to see if text can be passed to a script filter; in that case, I could save the text, and fill it to perhaps rerun the query. if it works, that could be an option for now. Currently, I'm copying and pasting. Perhaps a future option could save history for each filter, and perhaps even optionally bring up a filter in the previous state with queried results and scroll position.

[vitor]

I’m not sure I understand what exactly you want to accomplish.

 

If you want to immediately rerun the Script Filter with the same query, why doesn’t calling Alfred and pressing ↑ suffice?

[h2ner]

I'm hoping that script filters can be more robust and comparable to how one would use other search engines. There are filters that can return dozens, hundreds, or thousands of results. With many other search engines, one wants to act on numerous results while refining the query. If one has a filter that returns a hundred results, with the filter rerun and highlighting the first result (if using the up arrow), finding ones previous place with scroll position is more difficult. Plus, what prompted this thread in the first place, when calling filters from a hot key, unless I've missed some setting, the up arrow does nothing for me.

 

On a related note, it would be also helpful to see a history of query strings for a particular script filter, or even a list of previous entered strings for all filters + previous items (web searches, files, folders, …)  From what I've found, up arrow seems to be the only form of history save clipboard. Workflows is what made me attempt to switch from another app, yet I continue to use another for such features as history. In another, cmd-B will show a history of previous items. Plus when using another search, shift-space will fill in the text from a previous search, handy when wanting to enter in the previously used string into another search or filter, such as when wants to use the same string against multiple web searches.

Edited March 1, 2017 by h2ner

[deanishe]

13 hours ago, h2ner said:

comparable to how one would use other search engines

 

What do you mean by "search engine"? It's a very nebulous term to compare Alfred's UX to.

 

13 hours ago, h2ner said:

when calling filters from a hot key, unless I've missed some setting, the up arrow does nothing for me

 

This is one of several issues with Alfred's weird "external trigger" mode. Nothing entered in the ET UI ends up in the history.

 

If history is useful in your workflow, it's usually best to avoid ET mode. Use delimiters in your query and/or call your workflow via AppleScript to avoid external triggers.

 

For example, if you connect your Hotkey to a Run Script with the AppleScript tell application "Alfred 3" to search "YourKeyword ", that will open Alfred in normal mode where history works properly, instead of funky ET mode.

 

13 hours ago, h2ner said:

it would be also helpful to see a history of query strings for a particular script filter

 

It would definitely be handy to be able to view, filter and run items from the history.

 

I'm rather ambivalent about a per-workflow history. I guess it depends on how complex the queries you use are.

 

[h2ner]

9 hours ago, deanishe said:

What do you mean by "search engine"? It's a very nebulous term to compare Alfred's UX to.

 

Given Alfred's UX, indeed I do not hope for the power that's possible with an entirely different UX, yet the original scenario mentioned, wanting very very very very much to return to the previous state of a script filter, with same results and scroll position, plus a query string history if possible, stands. Rerunning the previous query could take time; if it were possible to cache state given some time out and restore, that might work.

 

9 hours ago, deanishe said:

This is one of several issues with Alfred's weird "external trigger" mode. Nothing entered in the ET UI ends up in the history.

 

If history is useful in your workflow, it's usually best to avoid ET mode. Use delimiters in your query and/or call your workflow via AppleScript to avoid external triggers.

 

For example, if you connect your Hotkey to a Run Script with the AppleScript tell application "Alfred 3" to search "YourKeyword ", that will open Alfred in normal mode where history works properly, instead of funky ET mode.

 

I'm not quite sure if I understand, having only started workflow dev, but I'll think about it. I'm not using an ET but a hotkey bound to a script filter; perhaps that too is part of ET mode. I don't know if there's any current way to export the query string to some variable or preference (that part yes) and then prefill the script filter with the last used string, maybe through some run script between the hotkey and script filter; I may do that if possible though a future browsable query history, or better that plus restore state, is very much more preferred.

 

9 hours ago, deanishe said:

It would definitely be handy to be able to view, filter and run items from the history.

 

I'm rather ambivalent about a per-workflow history. I guess it depends on how complex the queries you use are.

 

Yes, thinking about it, agree per-workflow history might be troublesome, but a hotkey to show some type of history list would be great. The mentioned other app that also permits cmd-space to fill in a previous string could be nice as well though I haven't thought much about if an item history + search string history would be more useful and how it might look.

Edited March 1, 2017 by h2ner

[deanishe]

12 hours ago, h2ner said:

if it were possible to cache state given some time out and restore, that might work.

 

It's a very common pattern in workflows.

 

12 hours ago, h2ner said:

I'm not using an ET but a hotkey bound to a script filter; perhaps that too is part of ET mode

 

I'm not sure the mode has a proper name. There's Alfred's "normal" window where you can enter keywords, and there's what I call External Trigger mode, where you're "locked" in a specific workflow. There's no keyword and you can see the workflow's icon on the right. Hotkeys, External Triggers and nested Script/List Filter windows run in this mode.

 

It works very well with contextual stuff like "Show me a list of scripts for the active application", but sucks for drill-down-type interfaces because Alfred's history will capture at most the top level and the only place you can go "back" to from ET mode is Alfred's empty query box.

 

12 hours ago, h2ner said:

I don't know if there's any current way to export the query string

 

Save it to a file.

 

[h2ner]

I’m not sure if since my first post there have been any changes or additional features that might help.

 

To better explain what I’m hoping for: I have a script filter that searches a database and returns results. Relevant results could be at least several dozen and sometimes a hundred or more. Just like a search engine, I tend to often look at several to a dozen or two of the most relevant entries, perhaps refining search and continuing. Ideally, a script filter could persist its state so the next time I run it, it doesn’t requery the database but is reinvoked with the same query text filled in if I wish to edit the text, the filter results list is the same, and cursor and scroll position is also the same so for example I could easily just scroll down one and choose the next result if let’s say there’s 100. Sometime there was the addition of using AppleScript to call Alfred from an external script. With persistent variables; can I perhaps set the query text as some variable and then have an action before my script filter that calls it with the previously saved query text stored in a variable? My preference is to use the external trigger mode bound to a hot key as like a search engine I may invoke it repeatedly to look at dozens of results. Is it worth the possible addition of a toggle so that script filters can persist state upon successive invocations? I imagine some may wish to do something similar, use a script filter repeatedly to examine numerous results while refining the search. 

Edited March 17, 2019 by h2ner

[vitor]

35 minutes ago, h2ner said:

persist its state so the next time I run it, it doesn’t requery the database

1. Type query in Alfred.
2. Check if it is cached, by looking for a JSON file with the same name in the cache directory. Is it there?
   1. Yes: go to the last step.
   2. No: after you convert the results to an Alfred-readable format, save it as a JSON with the query’s name to the cache directory.
3. Read the file.

42 minutes ago, h2ner said:

and cursor and scroll position is also the same

 

That you can’t do, because Alfred won’t save where you were in a result you haven’t actioned (which seems reasonable to me). What you can do is: after you action a result, modify your list so every result that came before the one you picked moves to the bottom. That way when you reinvoke it, the first result will be the next one in line from where you were.

 

Alternatively, save the position (i.e. how many results down) somewhere, and when you reinvoke, use AppleScript to press ↓ that number of times. I don’t recommend that approach: prone to errors and may take a while to complete.