A way to get back to the previous editing position after pressing Escape (without using the mouse)

• Sep 22, 2014 - 03:16
Type
Functional
Severity
S4 - Minor
Status
closed
Regression
No
Workaround
No
Project
MuseScore
Tags
accessibility

While using the keyboard, the editing position is sometimes lost and you go back to the beginning of the score. For example, if you add text or a rehearsal mark, or lyrics with Ctrl+T, Ctrl+M or Ctrl+L, you enter the text and then press Escape twice, you can no longer continue editing where you were. Either you press N and go back to bar 1 or you are forced to use the mouse to select a new position. It would be nice if after pressing Escape, the last known editing position is restored and you could continue exactly where you were before adding the text.

Or simply have a keyboard shortcut to get back to the last known editing position at any time would be great.

Also, I think Note Input Mode should be suspended when you add text.

Comments

• Nov 20, 2014 - 19:50

I think this should be considered a bug report rather than a feature request. When I press escape twice in note input mode or just once in regular mode, the cursor should not jump back to the beginning of the score but should instead stay where it is. This can be very frustrating for keyboard users like me.

Reply

• Nov 25, 2014 - 19:15

Andrei: I had given this a little thought, but not actually worked on it. Presumably the thing to do would be to restore the value of _is.tick(), if we can trust that this value is still valid. I'm not sure it always would be, though. What if you deleted the measure you had most recently been working on? _is might still have a reference to the now-deleted segment. Similarly if we had done a copy/paste that overwrote the measure you had been working on, or lengthened a note before the note you had been working on, thus "swallowing" the segment. Maybe some of these cases will update _is, but I'm betting not all of them do. So it might make sense to actually cache the tick value itself rather than trying to get it from the segment.

Reply

• Feb 5, 2015 - 20:08
Status (old) active ⇒ needs info

I'm not sure if we need to implement something here.
Instead of pressing Esc twice, you can press Esc only once and then use the Go To Next Element command (which now has the shortcut CTRL+ALT+SHIFT+ArrowRight, but you can change this shortcut) and you are back where you previously were before going into edit mode. I won't close this issue just yet, but I would like opinions on this work around. I would not want to start messing with the state machine transitions if it's not really needed.

Reply

• Feb 5, 2015 - 20:56

Well, it's still the case that one might hit scape multiple times accidentally, or just in an effort to get out of some undesired state. Right now I know youhave a PR to make the rest of navigation commands return focus to the score, starting at the beginning, I believe. I am not sure if there is a reason *not* to do this; I can't think of one, personally.

The idea that we might actually *remember* the most recently selected element is appealing, but there is no guarantee that element still exists - you might have just deleted it (and indeed, that might be how you lsot the selection). But I guess if we did maintain a "most recent cursor position", had delete and and related operations set it it to something else reasonable - like the next note after the deleted passage, or the closest chordrest - it would be nice to have the navigation keys return there instead of the begining of the score.

Reply

• Feb 8, 2015 - 14:35

I understand, but it is a bit unclear to me how this command should work when the element was not deleted. Should it try to restore the exact same selection (assuming that the element was not deleted), or should it try to select the say the first note/rest in the closest chordrest? From the way that this issue was initially filed I'm thinking that the second behavior would be more appealing.

Reply

• Feb 8, 2015 - 18:55

I would guess something like that, yes. I wouldn't so concerned with restoring a full selection, but rather the "cursor position". There is of course no true "cursor" except in note entry mode, but a single selection works more or less the same way as far as the user is concerned. If the selection is anything but single, I don't think it matters much if we take the first or last element or if indeed there a reliable indictor of an "active" (? I see this term in the source) element. It's mostly the single select case that I'd be concerned with.

Reply

• Feb 16, 2015 - 01:47

Thank you AndreiTuicu, I didn't know about Ctrl+Alt+Shift+Arrow, that does provide a workaround in some cases. Unfortunately, it doesn't work if you have multiple staves and you add a rehearsal mark from a lower staff, then this shortcut either doesn't do anything or goes to the top staff.

I think, in general it is wrong that Esc resets the position to bar 1. If you press Esc twice from note entry mode and after that you press N again, I would expect the cursor to reappear at exactly the same place you were, not go back to the beginning (it does correctly remember which staff you were editing). If that were changed, the problem with adding text would probably be solved too (I wouldn't mind having to press N again after Esc to get the cursor back, if it restores the correct position).

In the (rare) case that the last selected item was deleted, I wouldn't really mind if it did go the beginning (though going to the next/previous item would be more logical).

Reply