Ever since the last beta and the new 10.2.0.0 included, after the introduction of the new filename selection algorithms, I noticed unwanted behavior in my usual in-line rename operations.
In previous versions selecting the last string part in a filename before the extension (when extensions are shown in the same column) by double-clicking or using shift+Right Arrow selected the entire string up to the . of the extension.
In the latest beta and final 10.2.0.0 doing the same operations selects the string AND the . of the extension as well. Typing or pasting over it eats up the extension dot and so leads to more manual labor and a drop in productivity.
Visual Example:
before 10.2: "bla bla something.txt" > "bla bla something.txt"
now: "bla bla something.txt" > "bla bla something.txt"
If this is by any chance a design choice, I would very much like to know what lead to it being preferred over the old mechanic. Thank you.
We'll see if we can make double-click not select the dot without breaking the improved ctrl-left/right behaviour and ctrl-del/backspace support that caused the change.
Arghh... I hadn't upgraded to 10.1.0.3 or 10.2 just yet when this was first posted... so hadn't really appreciated the impact. I VERY often select part of the filename in inline rename mode by using Ctrl+Shift+Arrow to select the remaining portion of the filename UP TO the "." extension delimiter. The new Ctrl + Backspace / Delete feature is indeed a nice improvement that I would have otherwise looked forward to adding to my 'muscle memory'... but the inclusion of the "." in the selection of not just this new feature, but also in older/existing character selection mechanics like Ctrl+Shift+Arrow (in addition to the mouse click method daroc reported) is most definitely not an improvement! It's really frustrating and causing me to make mistakes that I have to go back and fix.
If I'm renaming a file... why would I ~ever want the "." selected, the deletion of which now leaves me with an extension-less file? I have to expect that the VAST majority of renames that most people want to do would NOT include stripping out the "." before the extension. So even forgetting that it's a big change to the muscle memory that some of us are used to after many years and several versions of Opus, it's otherwise just creating more work for people to do to get the intended result. We either have to back up one char in our selection to de-select the "."... or to have to retype the "." after unintentionally overwriting it.
Did I say shift+arrow i meant ctrl+shift+arrow and I use that more than the mouse as well
GPs is spoiling us with all these little touches. So much, that I've come to expect the same inline rename tricks to work in other programs, which they obviously do not...
Lets just wait and hope it gets fixed in the next build.
Yup, Ctrl+Shift+Arrow select also includes the dot.
Using that on the filename "testing.test1.test2.txt" when the caret is at the beginning selects all upto and including the last dot.
Same with files not having multiextensions, i.e "test.txt".
