I'm an avid user of shortcuts and I noticed quite some inconsistencies with the text fields along all DO interface. Particularly, the combo CTRL + BACKSPACE, to delete whole words (between spaces) is one of the combinations I use the most.
It works OK when renaming files or "Copying/Moving as...", but it doesn't work in other useful places, like the entering the name for a compressed file (in the "Add to Archive" dialog) or while editing the file type associations. These are just to name a few cases that don't work.
When pressing the combination on those fields, I get a "square" character instead of deleting the whole word. It happens something similar with CTRL + DELETE, which should delete the whole next word (as it works when renaming files), it deletes the whole line in those other fields that don't support that command.
To sum it up, would it be possible for all (most) fields to behave the same and be consistent with their usage? If not, would it be possible to at least add support for that combination for the most used fields (naming archives at least!)?
The field I meant was just an example that came to mind. I referred to the "Description" field in the "Edit 'New File Type'" dialog box. Of course, it doesn't work neither for the "Extensions", "MIME Type", etc. fields.
Maybe those are not really needed, but as you said, it would be great to have that handling on all the filename fields like the one in "Add to Archive Dialog".
Similarly - this is an area that has generally driven me a bit nuts for a long time ... I don't really use Ctrl+Backspace or Delete ever, but ALWAYS use Ctr+Left/Right arrows to move between filename or text field entries in various dialogs. There's a fair bit of inconsistency in what each part of Opus considers to be a delimiter that the Ctrl+accelerator keys (probably wrong word for this) will move between.
For instance, a dash or underscore in the string (without-any-spaces-between-parts) is handled differently in terms of where the cursor ends up being positioned depending on inline rename, vs in the location/path field, vs {dlg} type dialogs, vs Confirm File Replace and Copy As dialogs. Hardly the worst issue to deal with, but a real wreckage of something that for me is fairly ingrained muscle memory.
It's come up a few times over the years - but I think only a few of us have spoken up about it being desirable.
Ideally, it'd be great to have a Prefs entry to specify delimiters... which is what I have done in most text/code editors I've used as well as diff tools. But even without the ability to specify our own delim characters, consistent handling between the whatever default delims Opus would like to use across the different fields and dialogs would be enough to save me from constantly having to re-position my cursor to where I thought it should have gone. I think stopping on most non-alphanumeric chars makes sense - but I'll happily take consistent handling of hyphens/dashes and underscores as a start .
Are there any plans to look into these inconsistencies? They got more annoying and cumbersome the more I started using your app.
Another example that it's currently bothering me quite much is the "rename if file exists" on copying. When I try to copy a file to a folder where the same named element exist, I get the prompt to skip, replace, etc + rename right there. When I rename the file there, the cursor right sets the focus after the extension dot (instead of at the end, when renaming inline or in the classical way).
Will it ever be possible to unify all these fields? It's really difficult to remember before doing any action if:
Will CTRL + -> move me to the next separator here?
Will END move me to the extension dot or at the end of the text?
Will CTRL + BACKSPACE / DEL delete until the next separator or insert the awful ASCII square instead?
...
I downloaded the trial of DO 11 looking forward to fixes for this, but I've found none. I'd have bought it right away if it had them, as these have been the more annoying things I've experience of your great file manager.
The default for inline rename is to put the cursor at the extension as well. (The default can be changed.)
Fields for filenames will always have different handling to fields for general text (e.g. when editing the Description of a file) since filenames have extra behaviours that you would not want in general text (like treating the last dot in a filename as something special). So we will not be unifying all of the edit fields to have exactly the same behaviour, except where it makes sense to us to do so (e.g. fields where you enter a filename should have the same default behaviour unless there's a good reason not to).
The wordbreak delimiter setting Steje asked for above was added in Opus 11.
I understand that the fields should be unified where it made sense (that's what I meant). For example, the CTRL + ARROW / DELETE / BACKSPACE should be included in (pretty much) every field, the same as it works in Windows with most text entry fields.
The renaming-when-copying and and renaming inline (or via the "rename" screen) doesn't work the same way. On the copying rename, pressing right puts the cursor AFTER the extension dot, which happens because there's no special handling there (the cursor moves to the right of the current highlighted text).
On the other two instances, pressing the right arrow moves you to BEFORE the extension dot, allowing to sucesfully edit the last part of the file name without the extension.
... I don't really use Ctrl+Backspace or Delete ever, but ALWAYS use Ctr+Left/Right arrows to move between filename or text field entries in various dialogs. There's a fair bit of inconsistency in what each part of Opus considers to be a delimiter that the Ctrl+accelerator keys (probably wrong word for this) will move between.