TheQwerty wrote:So the documentation needs updated but quite frankly exiting rename mode via tab, mouse, or enter are different things entirely.
1) Exiting via Enter shows a complete acceptance of the new name, but no, nor lack of, intention to rename another item. As such it makes sense to treat each rename as a completed and separate action.
2) Exiting via Tab shows a complete acceptance of the new name and a desire to rename the next/previous item. In this case the new proposed behavior fits the scenario perfectly. It would be extremely confusing, even to a user that desires it, if the list re-sorted between each rename. Thus it makes sense to treat this as part of any number of rename actions; that is to say Tab does not exit rename mode, but changes the item being renamed.
3) Exiting via Mouse provides no proof of the user's actual intentions. After all, it's not the mouse click that accepts the rename it's the focus of another control/window, even if it was an unexpected dialog that interrupts the process. Now, in this case it's not even clear that the user wanted to rename the item or that they have completed the action when exiting rename mode. Thus it's arguable that accepting the rename at all is the desired action, and therefore performing the re-sort could actually be dangerous since it can cause the user to lose track of the item that may have been renamed against their wishes.
Thus it isn't a case of "a rename is a rename is a rename."
OK, let's break it down. First of all, let's define what a rename [operation] is. There can be no doubt that a rename [operation] is when file management software has detected complete acceptance of the new name, be it intentional or accidental. A program cannot reasonably differentiate whether a rename is intentional or accidental and we shouldn't have to expect it to do that. Also, it cannot second-guess the user's next step and, therefore, shouldn't make one particular assumption and discard any possible others. Now onto your points:
1) Completely correct and, in this case, the resort operation is [currently] triggered.
2) You are correct that "Exiting via Tab shows a complete acceptance of the new name" but that's as far as logic can take things. Saying that by exiting via Tab you clearly state your intention to rename another item is a dangerous thing to do, because what if that person has no such intention? What if he/she accidentally pressed that button when they wanted to press "CAPS LOCK" (or any button within close proximity) instead. We simply don't know this beyond reasonable doubt. However, what we do know is that there is a clear remedy to avoid possible confusion - disable the configuration setting called "Resort immediately upon rename".
3) This way of exiting has the same thing in common with the previous two ways - it "shows a complete acceptance of the new name". Your example illustrates the possibility that such rename is accidental. I am prepared to admit that there is a chance that such possibility is correct. On the other hand, you fail to address a possibility that loss of focus (via click of a mouse on another area) was intentional, which it could equally possibly be. Whichever possibility you side with on this one, the end is still the same - a file is renamed. Just like with point 2) above there is a clear remedy to avoid the possible danger of loosing track of this file that has been accidentally renamed - disable the configuration setting called "Resort immediately upon rename".
In fact, by default, this setting is optional on clean install of XYplorer. This vividly illustrates that it is not something that would be applicable to everyone "out of the box". However, those who make the
wilful choice to enable such setting should not be denied its full capabilities simply on the basis of possible pitfalls that other people, who
wilfully enabled it, may encounter as a result of wrong expectations and their failure to read about its powers as stated in the documentation.
XYplorer Beta Club
Please include the following information:
