Relative paths from indexed folders

[nektorom]

Feature Request: Allow entering nested paths after selecting an indexed folder

Hi! Thanks for the great tool.
Currently, after indexing a folder path, I can only type the folder name itself, but not a deeper path like folder/continue/my/path. It would be very helpful if the input allowed specifying sub‑paths directly.

Thanks for considering it!

[executordk]

An alternative workflow is when you have that folder (folder/continue/my/path example) in the input you can press 'tab' (or 'ctrl+tab' depending on settings) to expand the path and then you can have autocompletion (again 'tab' and/or 'ctrl tab' can also be used) from that folder path.

Another "trick" is when you have folder in input (or selected in list) you can press 'Ctrl+E' (expand) this will expand folder in the list, in the list you can then for example move to an item and press arrow key to have that item in the input, or press enter to open it, or press Ctrl+E to expand that item in the list (if a folder).

Some other tricks is also using shift+tab to reverse autocomplete etc.

The "depending on setting" I'm mentioning is this one.

If you require that last path (folder/continue/my/path example) often consider indexing that as well to avoid typing in long paths.

[nektorom]

I see. It's very useful, though not really obvious. thank you.
Anyway I think it would be good for user experience to trigger this function for folders, if a user inputs a slash or a backward slash at the end of the folder name, as it happens when you enter the full address from the beginning.

[executordk]

I see. It's very useful, though not really obvious. thank you.

Yes also both "tab" and "ctrl+e" is as also meant as an "universal" expand option, to also open paths for keywords, indexed programs, executables etc. that will be expanded to their path as well (if they have any). Another one of those non-obvious ones are "ctrl+d" that will copy the path of the current item to clipboard. Some of these can be found in the right-click context menu.

btw: if you launch one of these folders like folder/continue/my/path it will be in history and then searchable by any part of the path. I usually have my go-to folders in history and don't really bother indexing them or having them as keywords.

[nektorom]

I tried "ctrl+d", it opens the explorer. I guess you mean F8. I would make it as "ctrl+C" by default :) Why not?
Regarding the command history feature, I’ve noticed a small inconsistency. When I use the “Text start with” search type, it applies only for "History", but not for "Indexed items". It caused some confusion for me - I found an item once, but then couldn’t find it again in the history and didn’t understand why.

[executordk]

I tried "ctrl+d", it opens the explorer. I guess you mean F8. I would make it as "ctrl+C" by default :) Why not?

Ah yes mixed those two up. Ctrl+C is a well known shortcut for copying text in about all programs, so that is kind of reserved (but would make more sense as to naming convention).

Regarding the command history feature, I’ve noticed a small inconsistency. When I use the “Text start with” search type, it applies only for "History", but not for "Indexed items". It caused some confusion for me - I found an item once, but then couldn’t find it again in the history and didn’t understand why.

Ok it was implemented years ago, as far as I remember there was some reason for that, to avoid some annoying frequent case. Will just have a look to jog my mind.

[nektorom]

I might be misunderstanding how it works. Maybe it searches the “Indexed items” using two fields: command line and file name. But in History it seems to search only by the shortcut’s file name. For example, if I type “powershell”, it suggests the “Windows PowerShell (x86)” shortcut from the Start menu. But in History it won’t find it by “powershell” the next time and only matches if I start typing “Windows…”.