Hello,
Might be more of a FYI.
"Retain cursor position on inline rename" was turned on in 9 (and worked). Upgraded to 10. The option is still on but does not work 100%. In 10, it would always move the cursor to the end (before the extension) and not remember it's position. Turning this option off, apply, test, then turning the option back on fixed the problem.
In 10, with the option on, if you're on the dot before the extension and move to the next file, you'll be put before the dot/extension in that file as well (even if the filename is a different length). Maybe that's what seemed wrong? I think in most situations it makes sense.
Yes, that makes sense. But isn't what was happening. I was in the middle of the file name, click the arrow down and it would go to the end of the name (before the dot)no matter how long or short the file name was. Now that I turned it off, then back on, it's working like it should and not moving to the end.
I was actually a fresh install of 10 but I used my 9 config backup.
I also have an issue with this, although the on/off toggle didn't help (maybe its a bit different).
Lets say I have a couple of files like this:
Item 01 sometexthere.txt
Item 02 sometexthere.txt
Item 03 sometexthere.txt
Item 04 sometexthere.txt
Now I want to remove the "sometexthere" part by positioning the caret just after 01 and selecting that text (this works) and press delete.
Pressing the down arrow now positions the caret next to the "." in "Item 02 sometexthere.txt"
What I would like is to have it position it at the current position in the next filename if I wasn't at the "." position in the old name.
Currently it seems to detect if I am based on where I end up after the rename is done.
That's completely by-design.
If you are on the . of the current file then you'll be put on the . of the next file when you move to it. That way if you want to insert/delete text before the extension on a lot of files (which is very common) you don't have to keep moving the cursor to the end.
If your aim is to remove the " sometexthere" on the four files, the only difference it makes is pushing ctrl-left instead of ctrl-right. Not sure if that is what you are doing, though.
It may be by design, but it seems to have overlooked the case I mention.
after the suggested change, for the cases you mentioned earlier in the thread, it'll still do exactly the same, except when you're NOT at the "." position
in the old name. In other words, you wasn't at the ".", so most likely wouldn't want to end up at that position in the next file.
A more obvious example if you like:
Item 01 sometext.txt
Item 02 sometext some text some text some text some text.txt
Item 03 sometext some text some text some text some text even more text here.txt
Item 04 sometext some text some text some text some text even more text here lots and lots of more text here.txtNow, if you're selecting and deleting " sometext" from the first name by selecting the text just behind 01,
would you expect to be at the "." or at the current position in the next filename?
You want to do the same for all the files manually (some text is some random text which can be any length although the prefix might be the same).
This is the case where it should use the current position (i.e you wasn't at the "." in the old name).
Whatever we do, it's not going to be perfect in every situation because Opus cannot guess what your intentions are for the next filename. We have to decide what the most common situations are and try to make it work well in them, and not too badly in the others.
(In this situation, Find & Replace or Wildcard rename is a lot quicker anyway.)
I use Ctrl-shift right, and true, it's just a matter of left vs right if the lengths are similar, but it's sort of an unnecessary unintuntivity.
Lets say the order of the files was in random length order (not by increasing length as above).
If 1 and 4 was just after eachother, and you wanted to remove all the text after the number manually, would you:
#1 use ctrl-shift left lots and lots of times
#2 or would you rather use ctrl-shift end, then ctrl-shift left 3-4 times?
as far as I know, if it uses the current position you can use #2 for each file, otherwise only #1 is available.
Well, I tried to argument a bit for it.
Find and replace often helps, but sometimes not.
Wildcard rename is good too, but for f.ex 2-4 files (depending) rather than a few keystrokes, well.
[quote]I use Ctrl-shift right, and true, it's just a matter of left vs right if the lengths are similar, but it's sort of an unnecessary unintuntivity.
Lets say the order of the files was in random length order (not by increasing length as above).[/quote]
Now say you want to add (or remove) " - backup" to the end of each filename, before the extension, and the names all have random lengths...
[quote="leo"][quote]I use Ctrl-shift right, and true, it's just a matter of left vs right if the lengths are similar, but it's sort of an unnecessary unintuntivity.
Lets say the order of the files was in random length order (not by increasing length as above).[/quote]
Now say you want to add (or remove) " - backup" to the end of each filename, before the extension, and the names all have random lengths...[/quote]
That's the clue when I said "in the old filename".
If you position the caret in the old filename at "." the suggested change would still do exactly the same, but if you were'nt at the "." in the
old name it would use the current position instead.
For adding, you'll most likely position the caret next to "." initially and enter the text = at "."
For deleting you most likely position the caret next to "." initially and use ctrl-left.
both of these I'd like to have at the "." in the next file.
but, the difference here is "initially", not where you end up after the rename is done by select and delete in the case where after you deleted you
happen to be at the ".", while in the old name you were not.
Nothing is perfect, I know.. just a suggestion though. Sometimes something sounds easy while it isn't.
If you understood what I meant, but is against it, it isn't much I can do though. 
I'm not sure what you are suggesting.
How do you define "initially"?
[quote]For adding, you'll most likely position the caret next to "." initially and enter the text = at "."
For deleting you most likely position the caret next to "." initially and use ctrl-left.[/quote]
Using ctrl-left is positioning the caret, so how would Opus know that the "initial" position is meant to be where you were before you pushed ctrl-left and not after? Opus has no way to know your intentions when you move the cursor.
The only useful state I can see is the cursor position and/or selection just before you move to the next file.
The suggestion only affects triggering "." behavior or not.
Based on what you'd most likely know, when the file is renamed, and the "." condition you already use have been met,
if the new name is shorter than the old, and current position isn't at "." in the old name, revert to use current position.
This would require it to know old namelength, new namelength, current position.
hooh, that might've came out wrong, its somewhat hard to explain properly (my main language isn't english), but hopefully you got the gist of it.