Directory of selection: property selection.dir

[GasDauMin]

In some cases, would be very useful to have selection-based property "selection.dir" for directory only, just like command line modifier "%~dpN".

For example if we select path C:\Windows\System32\notepad.exe we will get parent directory C:\Windows\System32 and if we select path of parent directory C:\Windows\System32 we will get same path C:\Windows\System32. This is useful when we want to open shell in the path we are in and it doesn’t matter if we select a directory, directory bacground, drive, or a file.

[end2endzone]

Hi.
Thanks again for providing ideas and improving the software. That's a good idea. At first, I was thinking about selection.parent.path but the example you provided helped me understand your need. In my own words, I would say selection.dir is always mapped (forced) to a directory. If you select a file, it matches the file's directory. If you select a directory, it matches the directory itself.

About the timeline of this issue...
I was planning on releasing 0.6.0 this week. I plan on addressing the plugin api in version 0.7.0 which is a big leap from the actual code. I think this issue would suits well in version 0.6.0. Do you think you could complete this issue in a few weeks ? If so, I could delay the 0.6.0 release in order to include this issue. Or, we could plan a 0.6.1 which actually include this feature. What do you think?

[GasDauMin]

To accomplish this task, I created a separate branch feature-issue79 where have already implemented the solution, this time I added some unit tests and checked more diverse scenarios. Please feel free to review it and comment.

As you can see there are another branch feature-issue80 of changes. There are more related changes in this branch which I would also like you to review.

If everything fits, with your permission, I will be able to merge them with the master branch. For that reason there are two pull requests.

[GasDauMin]

Please help me with merging of branches i don't know how can fluently organize merging. Something wrong with mine feature-issue80 branch because it's contains feature-issue79 branch inside. Locally, I did something wrong while trying to merge the branches, so I ask for help so I can connect the branches correctly.

[end2endzone]

I am not familiar with the application that created this screenshot. I am using TortoiseGit. According to the 'master' identifier on your screenshot, this log seems to be from your master branch from your local git repository. The sha-1 'a11319c5' can not be found in my master or in remote/master. This gives me a hint that branches feature-issue80 and feature-issue79 are merged in your master but I might be wrong. But if I am right then you might have been confused about the merging process. From what I understand, your branches should not be merged into your master branch. These branches should be merge by github once the pull request for each branches are merged into the remote/master branch.

From what I understand, the process should be as follow:

1. Create a local branch for each issue number. (you did)
2. Push your branches to the remote repository. (you did).
3. Create a pull request for each of your remote branch so that github will merge each branch into remote/master.

You seem to have added an additional step (like 2.5) which already merged your branches in your master. This will probably induce conflicts when you will pull from remote/master into your local master branch after the PR are accepted (merged).

Also, when I do a "show log" on branch feature-issue79, I see the commit for issue 79 as 9d6312e which is fine. According to the graph, it is a commit in the branch itself (it does not come from another branch):

However, when I do a "show log" on branch feature-issue80, I see your fix for issue 80 in commit 45cb445 but I also see a commit about issue 79 in commit 5aed0bc. According to the graph, the commit 5aed0bc does not come from another branch (it is a strait line). To me, it looks like you committed the fix twice: once in branch feature-issue79 with sha-1 9d6312e and a second time in branch feature-issue80 with sha-1 5aed0bc:

Also, the changes about UserManual.md (about the new property) should have been committed in branch feature-issue79 but it was committed in feature-issue80 along with the files that fixes issue 80 (45cb445). This was a source of confusion for me when I reviewed PR #81. I noticed the documentation was not updated but I did not expected that documentation for the property would be in another PR in another branch.

If you want to reorganize the commits, you could do the following:

1. Move changes about UserManual.md in the right branch.
   1. Revert UserManual.md (45cb445) in feature-issue80. (Only revert stuff about UserManual.md. There is no need to revert all files.)
   2. Add a new commit in feature-issue79 for UserManual.md.
2. Revert the duplicate commit about issue 79 (5aed0bc) in feature-issue80.
3. Push branches feature-issue79 and feature-issue80 to github and hope that github updates the PR automatically.
4. Request peer reviews again for both PR.

[GasDauMin]

Thanks for the observations, I want traceability and correct order, the trouble is that I didn’t know how to act in that situation. Screenshot was made from Visual Studio and I Am using Visual Studio preferred git tools. I will try TortoiseGit perhaps it will not be as limited as VS git integration.

[GasDauMin]

Finally got it, as I can see there are no more incorrect overlaps and the files are all in their places.