I was thinking abou this, and i got to the conclusion that we might be over-complicating this problem.
The thing is that having farr parse a string in a way that makes sense is too dificult. And the 2 boxes- idea, just adds to the problem, as it becomes more and more dificult.
I have an inovative idea

How about instead of having poor farr trying to parse a string based on a lot of criteria, not have those rulles defined in each of the alias itself?
i.e. The alias would have the rules for what could come before or after it.
Right now, it is possible to do this, an alias with this regex:
(.txt) edit(.*)with this line of execution,
c:\programas\pspad\pspad.exe $$1 $$2 |pspad $$1 $$2Is close to execute what i'm referring to.
My idea is:
How about if initially, farr displayed every file and alias (the alias has to not need arguments before it) started by the letters you type.
Then, when you find the alias or the file you want, you press enter to launch it, or space to start another search based on your previous selection. Which means that if your first selection was a ".txt" file, "edit" alias could appear in the next option. If it was a .exe file, "edit" wouldn't have any sense, so, it doesn't appear.
What i mean is, have farr select a result on space, and the next results are based on that result.
This solution creates only 2 problems with prior requests:
1) The "f f" request, which would select firefox with the type of "f f", for which i can't find a solution other than typing "f*f".
2) The command line parameters solution, that i think can be fixed by adding a comma.I.E., "mini, capture" would make minicap capture the screen (if capture was the command line parameter that would acomplish that).
