After performing an inline rename on a selected file as a member of a very long filelist, the recently renamed file may become invisible since it is moved to the end of the list (outside of the current viewport).
Example:
Scroll to the top of a long filelist.
Rename a file from ABC to ZABC.
File is move to the end of the list but viewport doesn't follow.
Explicitly selecting the renamed file doesn't work:
It's by design, rather than a bug. It allows you to rename the file that came after the one you just renamed, which is often done when renaming a bunch of files one-by-one.
(Edit: See below. Not sure if it really was behaving as designed after further investigation.)
It's impossible to rename the next file because the focus/selection is moved also. In other words the (invisible) file is still selected. If you press F2 (again) the viewport will scroll down to edit the file at the end of the list. Same when pressing cursor up/down.
Anyway, if the user wants to edit files in a sequence he can press cursor-up/down instead of return. Thus it's ok if the latter scrolls down to make the renamed file visible again.
Maybe it's an option to let the user change the script to let him decide which behaviour is desired. Unfortunately the following commands doesn't work as expected:
That doesn't happen for me, except when I rename the very last file in the list (which seems to be a bug; I'll fix that).
[/quote]
I didn't mean that renaming by pressing cursor up/down doesn't work at all but it's not possible to rename the files 1-5 in a sequence by only pressing return because the selection as well as the focus is moved together with the renamed file but the viewport doesn't follow.
In other words after a file rename action the viewport stays at index 1 but the file, the focus and the selection is on 5000 (where the file is in-sorted). If you press cursor-up the viewport will follow and the selection is on 4999.
That's not true because the focus and the selection is moved away (e.g. to the end of the list, which may be thousands files away from your current viewport).
I do not like that behaviour also, but I'm sure that it can be configured in the options.
I have a look to the preferences and there are no options affecting this behaviour.
Actually if I only rename a single file (using inline mode by pressing F2) and finally I press return it doesn't make sense to me that the file is moved away (including the focus) but the viewport doesn't follow.
Leo, you said that it is by design?
What is the usecase where this behaviour has an additional benefit (when renaming a single file by pressing F2 and ending with Return)?
We've got some fixes and changes to how this works coming in the next beta version.
When you hit return after renaming, the keyboard focus will always stay with the file you just renamed, and the window will scroll to keep it visible, if needed. (We decided that, whatever the old design, what you said makes sense: If the user wants to edit files in a sequence he can press cursor-up/down instead of return.) While testing with various options and situations, we found some inconsistencies which should all be resolved, too.
Once the new beta version is out (no firm date yet, but probably in the next few weeks), please give it a try and let us know if you notice any misbehaviours in this area.
Inline renaming works very nice now, the viewport follows the selection in all cases I have tried.
Unfortunately the selection will be lost when renaming with implict creation of a subfolder.
Example:
abc.txt -> 2/abc.txt
I would expect that the newly created folder "2" will be selected (similar as on renaming without moving) to be consistent to the normal renaming behaviour.