I have figured it out ... feeling so stupid for not having it in the first place
Anyway based on some input from 2Fla$her in another post I came up with this:
"I used to feel guilty in Cambridge that I spent all day playing games, while I was supposed to be doing mathematics. Then, when I discovered surreal numbers, I realized that playing games IS math." John Horton Conway
cd \[foldername] dos NOT work only cd [foldername] does....
if you start with a \ you have to give the complete path!
example:
you are in folder d:\downloads and want to change to d:\downloads\some\files you have to use cd some\files
you are in folder d:\downloads and want to change to d:\work\recent you have to use cd \work\recent \ after cd means you start from drive root.
example:
you are in folder d:\downloads and want to change to d:\downloads\some\files you have to use cd some\files
you are in folder d:\downloads and want to change to d:\work\recent you have to use cd \work\recent
\ after cd means you start from drive root.
20.08.24 Added: Change directory via "cd" command: Append \: to go to the parent and place cursor on directoryor archive, e.g. cd c:\windows\system32\: (32/64)
It was a coincidence that it already worked with archives - TC would try to open
c:\path\archive.zip\:
as a directory and fail. Then it would try opening
c:\path\archive.zip
as a directory (not archive!) and fail too. Then finally it would try opening
c:\path
and succeed. Now this has been implemented to directly go to c:\path instead
and set cursor on the archive.zip file.
Yes, I understood that it worked because of a fail, but it worked nonetheless. Thanks for the folder anyway!
I hope you will still mature to the rest of the wishes from the list.
20.08.24 Added: Change directory via "cd" command: Append \: to go to the parent and place cursor on directory or archive, e.g. cd c:\windows\system32\: (32/64)
Does not work with relative paths, e.g. cd Language\:. Is that how it should be?
I would like to again support the proposal of *Fla$her in this topic.
I am not sure how this would work, but I imagine the solution as an upgrade or a step further of the implementation currently applied for the cm_CompareFilesByContent command
there just needs to be a way to replicate the same solution but for a given by a variable path string and instead of opening it to be able to just pin it in the destination panel.
I suppose there is a challenge... after all the list of objects in the panel is provided by a third party... the plugin, which is difficult to control
so my hope is that TC can traverse the path as it does with the internal command and then get a list and not just the content of the file for the comparison.