Wondering if you could consider providing access to a Tab's back/forward history...
I really only need the immediate previous/next paths from current position, but wouldn't object to the full set of each.
I was thinking/hoping you could do something like:
Tab.Path.prev - could be either a string return with the immediate previous path in the Back history, or better yet, a Vector with the full Back history. Tab.Path.next - could be either a string return with the immediate next path in the Forward history, or better yet, a Vector with the full Forward history.
It could also be useful if there were respective test_prev and test_next properties that could behave like test_parent or test_root.
Because no good deed goes unpunished - if you were able to make a property such as that mentioned above a Vector to provide access to the entire back/forward history list(s), then it'd also be useful to be able to run a Go BACK or FORWARD command that let us move to one of the positions in the list directly... such as Go BACK|BACKLIST 3, where adding the numeric value after the BACK or BACKLIST option(s) would cause Opus to move to the 3rd chronological position in the back history.
Use-case: if we have access to the history lists inside of scripts, we can then make decisions about using the list to navigate around and preserve and re-use the history, as opposed to doing explicit Go PATH commands that just keep adding to the history lists. The intent here would be to mimic what would happen if you were to long-press the mouse button on a standard Go BACKLIST button and then selected an entry from the history list further back than the immediate previous path.
And thinking through some more - maybe any theoretical property names like requested in the first post might be better off as Tab.Path.backlist and Tab.Path.forwardlist to more closely align with terms used in the RAW Go command.
Piling on... would also be really useful to have a generic way of testing if a read of a Path would work.
I thought that's what the test_parent and test_root properties were meant to do for parent and root dirs respectively, but now I'm not sure.
Either way, whether by something like having a Path.test property that could return True if a read of the path would work, or False if it would fail (permissions error, doesn't exist, etc) or by some other generic means, it would help be able to make smaerter decisions about changing paths beyond whether or not the path simply exists or not. For instance, if not part of the Path object itself, perhaps something like another FSUtil method (like FSUtil.Test), or perhaps an additional argument to FSUtil.Exists(string:path,string:flags) where a flag value of t could additionally test access to the folder if it DOES exist.
Thanks. I did look at that, but it seemed a heavier operation than what I was looking for with having to Close the handle used to enum the folder. Was hoping for something more lightweight that I wouldn't have to perform cleanup against if just trying to use it in a conditional test - especially if being run against a folder path with lots of items.
I'll try that to see if it slows things down much... thanks.
Ok, that to the side - it was a follow-on request after starting down the Path object rabbit hole from the original two posts that are more relevant and still of interest.