While typing in a text box, "Accessibility: previous/next element" is allowable, but not while editing other elements such as a slur

• Sep 27, 2019 - 00:43
Reported version
3.2
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

When custom shortcuts are utilized, this becomes an issue. If the user makes an alpha-letter be the shortcut for "Accessibility: next/previous element", this will interrupt, for instance, while typing in a staff text. You might say, "Well, that's the price you pay for trying to make a letter be a shortcut for such a thing," and I might agree. The problem here is one of inconsistency and inconvenience.

For example, if the user has a slur and activates the "Edit Element" command while doing so with a slur, "Accessibility: next/previous element" is disabled. Here is the gripe. If you were to allow such behavior as above, in a sense this activity should be reversed: why should it be disabled while editing a line or a slur, but then while typing in a staff-text, it's enabled to go to next element? Either both should be the same, or better yet, disallow moving to next element while typing, and allow for it while dealing with nodes of lines.

Of course this may call for some discussion, so this will be merely a suggestion for now, but it is definitely worth dealing with in the future, albeit's not a critical situation. Although, again, for the user who uses A-Z as shortcuts for navigation, this will screw up some activities.

Aside Note: A quick workaround for typing [A-Z] when alphas are set up as shortcuts that are affected while doing activities specific to text entry: use [ALT+Alpha] and the text will be entered, bypassing the A-Z shortcut.


Comments

Well, making typable character be a shortcut for a command that's active in text edit mode is not a good idea, for this reason.

As a separate issue, indeed, we could eventually come up with a meaning for this command in other modes and implement whatever we the consensus decides the meaningful behavior should be. The command does something extremely specific in text edit mode (it's not just, go to next element, it's find the next note and then find if there is a similar text attached to it and edit that instead, or else add a new text elements - basically, a poor man's "fingering mode"). That same exact behavior simply doesn't make sense for other edits modes.

So feel to start a forum discussion discussing a new proposed behavior for the command in other modes. One possibility is to simply leave edit mode and then do its usual function in normal mode, which is to move to the next element.

In reply to by Marc Sabatella

Thanks for pointing out that it's like a poor man's fingering mode, as that makes sense --- to use the function 'next/prev chord' while typing in staff-text will jump to next available chord and prepare for another staff-text if one isn't there, and apparently this is by design, which is why apparently a slur for instance while in "edit" mode doesn't allow for moving to the next chord by the same shortcut function. Still, feels a little weird at first.