Shortcuts are not always considered in the proper context.
I have moved this discussion to the forum where it properly belongs. It started in #260701: Cannot type the letter "a" anywhere in Muse Score.
I searched the issue tracker for "shortcut" for everything that was last updated a year ago or earlier and found nothing that would indicate this has been fixed. If it has been fixed in master I don't know since no issue from the last year concerning them has been addressed.
As far as a plugin shortcut being usable inside a text box of any kind I can't think of any reason one would be permitted to run because it should only affect in contents of the text box and I can't think of one that would be useful. If anyone can think of such a shortcut I will concede that plugin shortcuts should be possible for use in text boxes. In that case, plugin shortcuts should then be limited to only key sequences that use Ctrl and/or Alt (or the the equivalent on non windows machines) to prevent displayed key strokes from being disabled by their being defined.
Apparently the shortcut manager does not do a good job of taking context into account except in certain situations (such as Marc's space bar example). This is the reason F2 was problematic at one time. I would prefer some details to be worked out with a link to this discussion so the issue report will not be encumbered with this discussion. This will enable the request to be more precise for whoever (hopefully) ends up fixing it.
Comments
Actually, as far as I know, in general the shortcut management system does take context into consideration quite well; it's just that plugins specifically are handled a bit differently and not as well.
To understand how things are supposed to work, see the shortcut definition file:
https://github.com/musescore/MuseScore/blob/master/mscore/shortcut.cpp
You will see that for each command, there is a list of the specific states that are valid. For instance, the "parts" command is explicitly listed as being valid in STATE_NORMAL, STATE_NOTE_ENTRY, or STATE_PLAY (those names are hopefully self-explanatory).
This means that the shortcut defined for this command will work in any of those states, but not in any other state. The command is thus not valid in STATE_EDIT (edit mode), for example. Meaning you can define a shortcut like Shift+P for the parts command, and that shortcut would then not be available for any other command that is valid in any of those same states. If you try to define Shift+P to also be the shortcut for the "previous element" command, for instance, you'll get a conflict.
But there are some commands it is safe to use this shortcut with. For instance, the "previous beat" command is only valid in STATE_HARMONY_FIGBASS_EDIT (entering chord symbols or figured bass), and the "parts" command is not valid in this state. Thus you can reuse Shift+P as a shortcut in this state. Of course, doing so now means the letter "P" can't actually be entered in a chord symbols, except via the "Special Characters" dialog, but that's the user's choice.
I say all this so you understand how things are supposed to work, and do work everywhere but for shortcuts. Unfortunately, we don't really know up front what context a plugin might make sense in, so we just arbitrarily pick a single set of states for all plugin commands. Whatever set of states we pick is surely good for some plugins but not others. And we don't always do a great job of detecting conflicts with other commands that are valid in these same states.
So no doubt there are specific bug reports worth filing here. But that's what it comes to: deciding what the best set of states are for plugins generally, and making sure we correctly detect conflicts.
Note that normally you cannot define "A" to be a shortcut for a plugin, because it conflicts with the command to enter the note "A". But multi-stroke shortcuts are supported - like needing to press "A B C" in sequence - and this is how the user in question managed to shoot himself in the foot. Although trying to define "A" would have detected a conflict, trying to define "A B C" did not. But since plugins are generally available in text mode, it as a bad idea to have done this, just as it would be a bad idea for use Shift+P for "previous beat". Still, it's hard to prevent users from shooting their own feet...
In reply to Actually, as far as I know,… by Marc Sabatella
Proposal: To prevent conflicts and mistakes; User-initiated shortcuts (and shortcut sequences) should start with Ctrl. or Alt.
In reply to Proposal: To prevent… by Ziya Mete Demircan
Sorry, I didn't see your comment yesterday. In my opinion, there are too many unused single characters in the shortcuts to prohibit their definition by the user. I have used many of these as well as several that start with Shift. The error checking for available shortcuts is usually sufficient (See below).
If you are referring to plugin shortcuts, I agree since single characters cause problems in text entry. I did some further testing on plugins to see how they work in text entry mode. Plugin shortcuts run the plugin while in text entry. I found a problem with plugins though. I tried to assign A to a plugin and there was no warning. Since pressing A in every other context that I'm aware of does something, it should have warned of a conflict like it does if you attempt to define it in the Preferences... window.
In reply to Sorry, I didn't see your… by mike320
I thought it was necessary to block this for the Plugin-Shortcuts. (Apart from the normal shortcuts window, there is no control mechanism here)
Reason: If a key is defined as a starting key of a multi-stroke shortcut: After pressing the first character, the software waits for other characters to be entered; And this char. (key) becomes unusable.
If the first key of the multi-stroke-shortcut entry is forced to Ctrl or Alt, the user can't fall into this fault. (for the Plugin-Shortcuts)
And Just a suggestion. if there's a way to do it.
In reply to Actually, as far as I know,… by Marc Sabatella
To help my understanding of how it's supposed to work. In the case of Undo, Redo, Cut, copy and paste among others. The legal states include STATE_TEXT_EDIT however, when you are editing staff text for example Undo and Redo will not work, they tell the user "Command not valid in current state" So how do you get into STATE_TEXT_EDIT? This is the only state that makes no sense. The other definable shortcuts in preferences seem make sense as far as their states are concerned at first glance - except STATE_TEXT_EDIT.
Next, defining a shortcut as "ABC" should be recognized as a conflict because pressing "A" alone has a definition and the "BC" are not treated as part of the shortcut. I used what I believe to be the harmless "() Add brackets to element" as a test. I assigned the shortcut "ABC" to it. In every situation I got the usual results of pressing A then B then C depending upon what was selected. The result is that the note A is inserted somewhere followed by B and C. Furthermore, it did not affect text entry. The point of this of course is that in the example of ABC, there IS a conflict that should be identified by MuseScore. An example of what is not a conflict is the default definition of "Add ottava 8va" (Ctrl+Y, Ctrl+O, Ctrl+A) and "Add ottava 8vb" (Ctrl+Y, Ctrl+O, Ctrl+B) because no shortcut is executed until Ctrl+A/B is pressed. The shortcut manager should recognize whether it is a conflict or not. In Writing this I realized that I had assigned Ctrl+Y to "Redo" which is a common Redo shortcut and, in doing so, I disabled the ottava shortcuts. I should have been given a warning. I don't normally use shortcuts for ottava so I never noticed this before.
My favorite quote of the day is your final sentence "it's hard to prevent users from shooting their own feet..." This is very true, but a good program should do its best not to allow users to shoot their own feet and in the area of shortcuts there is work to be done to this end.
In reply to To help my understanding of… by mike320
STATE_TEXT_EDIT is exactly what you think it is - what happens when you double click a text element to edit the text. The shortcut for undo is "valid" in this state indeed, in that MuseScore at least attempts the operation. It's just that it isn't actually implemented, so the operation fails, and yields the message :-). It's not that much different from say, paste with tuplets across barlines. If you are in STATE_NORMAL, that's enough for MuseScore to at least attempt the paste operation, it just doesn't succeed. Since there are no cases currently where undo will work in STATE_TEXT_EDIT (as far as I know), probably we should just remove STATE_TEXT_EDIT from the definition of the command until that is implemented. That way MuseScore wouldn't even attempt the operation.
I am not really a fan of multi-stroke shortcuts, so I don't have a clear sense of user expectation of how they should work. I'll defer that to someone else. But I will just note they are a standard Qt thing, so at least some users accustomed to this facility in other Qt-based programs will have expectations we shouldn't disregard lightly. How to trade this off against the desire to prevent own-foot-shooting remains an open question to me.
In reply to STATE_TEXT_EDIT is exactly… by Marc Sabatella
I use multi-stroke shortcuts for things that make sense. For example, I use shift-R (for repitch) plus some other key strokes to enter accidentals. Using one base key stroke to remind me I'm about to enter an accidental is easier for me than trying to remember 5 different key strokes or more importantly trying to figure out 5 unused key strokes that would make sense for the five accidentals. I also assigned multiple key strokes for bow up and bow down, because the logical single stroke key commands were used elsewhere. It also enables me to assign shortcuts I can use without moving my hands from their usual places on the A-F keys and the numeric keypad. I don't know that I've used any other Qt based programs but I'm glad the multi-stroke shortcuts exists. This is one of a few programs where I have actually entered my own shortcuts. When used properly, they speed things up and help me to avoid confusing myself.
As far as a trade off to prevent foot-shooting is concerned, some better conflict checking should be implemented.
In reply to I use multi-stroke shortcuts… by mike320
Yes, I agree that multi-stroke shortcuts (I guess they are officially known as "key sequences") have potential advantages. They just scare me a little because they seem inherently ambiguous and thus unpredictable in cases where an initial sub-sequence is possibly used as a shortcut for as different command, so I'm reluctant to rely on them. I should probably get over it. Note that in 3.0 it will probably become possible to assign shortcuts to any palette item (implemented but not yet merged for master), and/or ability to navigate palettes by keyboard, which will change the picture some.
As for ordinary (not key sequence) conflict detection, and other aspects of shortcut management, as I mentioned, there have already been improvements implemented for master. This was part of work done for Google Summer of Code recently, with two different projects touching on this. I don't know if there have been any changes specifically relevant to key sequences.