Lines: when end handles are adjusted with keyboard arrows, anchor point also shifts

• Aug 20, 2020 - 13:09
Reported version
S5 - Suggestion

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit):, revision: 43c5553

  1. Open the attached file.
  2. Select the start handle on the barré line and move it using the Right arrow, or Ctrl + Right arrow.

Expected result: Anchor point stays where it is.
Actual result: Anchor point moves to the next note.

See also: Don't move anchor points when hairpin ends are moved.

Attachment Size
anchor_point_jumps.mscz 6.36 KB


In most cases, in order to keep the ends of the line, including "Begin" or "End" text, at the correct position, it is necessary to allow the anchor to snap to the following or previous note: not an ideal solution.

The use of arrow keys, and Ctrl + arrows, to adjust the handles, without affecting the anchors, needs to be restored.


This is really giving me some troubles today. I prefer the former behavior where I'm in control of anchors.
At least, there could be some kind of 'threshold' or tolerance before the grip jumps to the next or previous segment. Maybe dragging the grips should only change anchors when 'touching' or coming close to the center of a segment and not its boundaries - in a similar way that dragging slurs grips change only when touching a note.
Definitely, the arrow keys shouldn't change the grips unless using the proper key combinations (as in previous versions).

My proposal is that we have all keyboard adjustments continue to not move the anchor, except of course Shift+Left/Right. So, Left/Right on their own or with Ctrl would be to line length only, no change of anchors.

For the benefit of mouse users, I would also propose a modifier to suppress the anchor change. Ctrl is already used to constrain dragging to horizontal only (relevant if the line allows diagonals), but I don't see any harm in having it also suppress anchor change. I might suggest Alt, since it is used during normal drag operations to disable autoplace and somehow this seems vaguely similar, but on my system, Alt+drag doesn't actually work because Alt+click activates popup menus. Probably there is some way for me to change that in my OS settings, but anyhow, right now I wouldn't have an easy way to test any change to Alt+drag.

BTW, the crash with dynamics is related in some way of course, but lines don't crash, only dynamics. So, not really related, I think the anchor rebase code for lines is more robust in the case of multimeasure rests.

Status PR created fixed

Fixed in branch 3.x, commit f7245e989e

_fix #309368: suppress anchor change on keyboard nudge or Ctrl+drag


Currently, dragging or keyboard nudging the end handles of a line
will always try to find a new anchor point to attach to.
This makes it virtually impossible to obtain certain layouts
where you deliberately want a line to extend before or after a note
but still be attached to that note rather than the previous/next.

Thre solution here is to simply disable the rebase of anchords
when using the keybaord to perform the adjustment.
In addition, for mouse users, I allow the Ctrl modifier
(which also constrains drag to horizontal)
to perform this same function._

Fix version