Jump to content

File Filter - Retrieve Original Query Parameter


Recommended Posts



When using a File Filter or List Filter, sometimes we need the original query, not just the filename or list item output. Here's my example: 


  1. Use File Filter to search in a folder and within PDF documents for a work order number. For example: wo 12345
  2. A list of PDF's that contain that number are shown.
  3. Open PDF file in Preview. So far, everything works as expected.

Then I would like to take the work order number, in this case 12345, and enter it into Preview's search field. But, I don't have access to the original query. It would be nice if Alfred would save the original query as an internal variable when using File Filter, similar to {query}. How about {original} or something.


I have tried using a Keyword first, to grab the original query, but then I have to hit enter to see the results. This breaks backspacing to refine the search.



nikivi originally brought up the topic and I have a similar post in this thread: 


Link to comment
Share on other sites

In a case like @Codeplus's where you're searching file contents, keeping a reference to the original search query would be a significant boon to integration, as you could put it on the find pasteboard and have Preview (and other apps that support NSFindPboard) automatically search for the query when the file actioned in Alfred is opened in the app.


More broadly, I'd include the original query with other workflow-specific state that Alfred really should share with the workflow, such as the workflow's data & cache dirs (available) and the keyword used to call an action (not available).

Link to comment
Share on other sites

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.




Link to comment
Share on other sites

49 minutes ago, Andrew said:

the keyword is user editable


That's precisely why I'd like it available via a variable. If it weren't editable, I could safely hardcode it. Using {var:KEYWORD} for the keyword is user-unfriendly and fragile.


49 minutes ago, Andrew said:

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.


The use case, basically, is working with Alfred's history and being able to go back within a workflow.


That is to say, if I've searched for something, then drilled down into a list of details/options/whatever, I want to be able to back out of the details to the previous query & results or re-open Alfred and go straight back to that list of details.


Both of these are doable using delimited queries and AS to go back, while neither works with External Triggers. They are ignored by Alfred's history and the only place you can go back to is an empty Alfred query box (i.e. start all over again).


Personally, I use Alfred's history an awful lot, so not having those drilldown results in there would seriously reduce its usefulness (to me).


There are workarounds for the "going back" issue, but not for the history, so I still use AS instead of External Triggers in many workflows.


Adding External Trigger support to Alfred's history strikes me as difficult and likely to break workflows, so I'm asking for a technically far simpler option: an alfred_workflow_keyword variable.


That way, my workflows won't (mildly) break when the user changes the keyword.


Link to comment
Share on other sites

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

  1. Straight up typing stuff in
  2. 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)
  3. 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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 year later...
  • 1 year later...
  • 3 months later...

@Andrew any chance this gets implemented?


Specifically it's really nice for workflows where you're searching the content of a file. e.g. `nb query` to search for "query" in markdown files, then execute a Vim search for the query to immediately highlight occurrences.

Edited by babramczyk
Link to comment
Share on other sites

  • 2 years later...

Just doing my yearly check to see if this feature has been implemented yet. I guess it's still a no go. This seems much easier to implement than most of the other features in Alfred. But, I only make in-house utilities in Swift. So, maybe it's much harder than I think.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...