I know control codes are mainly for dealing with external apps... and most external apps won't necessarily know what to do with a path like "lib://My/My Media". That said, there are times where I need to put a path into a variable and then do other internal Opus stuff as opposed to sending it to an external app. With {s} resolving to the physical path, this leaves me at a bit of a disadvantage in preserving the virtual path for such use-cases...
Would it be possible to have an extended {s} control code variant that would preserve the virtual (library) folder paths... something like an {sV} control code or something similar? Having such in any use-cases that would benefit from it would avoid the substitution of virtual to physical paths from:
-
causing actions against library ROOT paths to not operate on all possibly intended datasets... i.e. if I'm sending the root of a library path to some other function (user command, etc), the {s} control code will resolve the library root to only the default save location, so depending on what I'm doing (Find, flatview, recurse rename, etc) I would miss a large portion of the intended dataset.
-
re-positioning and lengthening the view in the folder tree, particularly down deeper in a library folder structure. I already have the virtual path opened up in the lister, and opening up another tab will then open that same directory structure under the physical folder path.