fix #63176: note input cursor glitches in voice 2 #2033
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes both issues listed in the original report.
Bug A is handled with the code involving "keepSelected". Basically, I detect the case where there is no cr at input position, so I fall back to the selected note, but also set a flag saying not to then go back one step from there. It is conceivable some case might exist where this prevents the cursor from moving backwards in places where it actually should, but I can't actually make this happen. I was especially concerned about navigation in the presence of grace notes, but so far so good.
Bug B is fixed with code to explicit select the cr at the input position if you try to move to the next chord but there is no next chord. Otherwise, the input cursor was being advanced and we were losing any chance of finding the current chord.
One kind of bothersome thing I realized while looking at this code: we are spending quite a bit of effort managing the input cursor via moveInputPos() for each command, when really, it seems the act of selecting an element does this for us in many cases. Sometimes we call moveInputPos() with one position, then end up selecting some other element and the original moveInput() gets clobbered. It actually does the right thing in the end - I think we could probably eliminate some of the moveInputPos() calls. But this code has been very delicate over the years so I didn't make any substantive changes.