Alternative title: Create separate Move Single Line keyboard shortcut
Alternative title 2: Remove new list line movement logic (but I know dev time already went into this and some people may like it so that’s unlikely)
The new line movement logic added to lists in the latest release actively hinders keyboard only edits of notes. Things that used to be easy are now either impossible or significantly harder to achieve without using the mouse or a combination of Selection + Copy/Paste.`
The keyboard shortcut is “Move Line” not “Move item, and it’s nested components, and don’t leave the list”. However the new logic expects you to break your current assumptions of what that shortcut does when specifically inside a list.
I will also throw out that the new behavior of “move an item and it’s nested children” already existed. You just had to select multiple lines and then perform the command. In this way it’s a conscious decision on the user’s part to move multiple things, not some hidden logic you have to learn the quirks of.
(for all examples I have Alt + Up bound to Move line Up and Alt + Down to Move line down, sorry if this causes confusion)
Example 1, un-nesting
Moving a nested item to a top level item. Commonly done when re-arranging priority on a task list for example
Starting with
* Item 1
* Item 2
* Item 3| <-- cursor
* Item 4
* Item 5
Say you want to move Item 3 to the top level above Item 1
* Item 3| <-- cursor
* Item 1
* Item 2
* Item 4
* Item 5
Previously this was a combination of 2 Shift + Tab and 2 Alt + Up presses in any order. This could also be perfectly reversed by 2 Tab presses and 2 Atl + Down presses
With the new system you run into 2 major problems.
- Items can’t “leave” a nested list
- Nested items are “dragged” along with an item even if they didn’t start connected
From the starting position pressing Alt + Up does nothing because it’s nested under Item 2 and it can’t “escape”.
So instead we have to hit Shift + Tab first to get it into the parent tree.
* Item 1
* Item 2
* Item 3| <-- cursor
* Item 4
* Item 5
From here there’s 2 sequences we can take
Shift + Tab again then Alt + Up which results in:
* Item 3| <-- cursor
* Item 4
* Item 1
* Item 2
* Item 5
Or Alt + Up then Shift + Tab then Alt + Up again which results in
* Item 3| <-- cursor
* Item 2
* Item 4
* Item 1
* Item 5
Both have problems because they drag Item 4 and/or Item 2 with them as those items become “newly nested” under Item 3. This would require even more movements and editing to move 2 and 4 back into the right locations. Overall much more annoying and complicated than just “Move line” like previously possible.
On top of this route being longer and requiring remembering a much more specific sequence of key presses it’s not easily reversible. see next
Example 2, nesting an item
To place Item 3 back where it was from the top level starting like this you have a few options
* Item 3| <-- cursor
* Item 1
* Item 2
* Item 4
* Item 5
Tab x2 Alt + Down x2 - but this only works if you remembered to hit tab first
As of the 1.15.1 change “Smart lists prevents over-indenting list items more than one level deeper than the item above it.” This is no longer possible. You must use the “overshoot” methods below
* Item 3| <-- cursor
* Item 1
* Item 2
* Item 4
* Item 5
---
* Item 1
* Item 2
* Item 3| <-- cursor
* Item 4
* Item 5
Alt + Down ,Tabx2, Alt + Up
* Item 1
* Item 2
* Item 4
* Item 3| <-- cursor
* Item 5
---
* Item 1
* Item 2
* Item 4
* Item 3| <-- cursor
* Item 5
---
* Item 1
* Item 2
* Item 3| <-- cursor
* Item 4
* Item 5
or Alt + Down, Tab, Alt + Up, Tab
* Item 1
* Item 2
* Item 4
* Item 3| <-- cursor
* Item 5
---
* Item 1
* Item 2
* Item 4
* Item 3| <-- cursor
* Item 5
---
* Item 1
* Item 2
* Item 3| <-- cursor
* Item 4
* Item 5
---
* Item 1
* Item 2
* Item 3| <-- cursor
* Item 4
* Item 5
The second and third options feel very weird to have to hit Up because the first down “overshoots” the place you wanted it to land. If the 2nd level was longer you may have to be press Up many times just to get back to where you wanted it to be.
Again I will point out that the previous situation was very intuitive, move down twice and over twice, 2 Tab and 2 Alt + Down in any order
Example 3, combining/moving between lists
Starting with this, note the blank lines around the paragraphs.
Description of list 1
* Item 1
* Item 2
* Item 3
Description of list 2
* Item 4| <-- cursor here
* Item 5
If you use the “move line up” command in the latest version to move Item 4 up from the second to first lists you end up with this:
Description of list 1
* Item 1
* Item 2
* Item 4| <-- cursor here
* Item 3
Description of list 2
* Item 5
The instant Item 4 is above the description line it’s considered as part of the first list even though there is an empty line there. Then the next “move line up” command swaps it with Item 3 instead of just moving the line up to be “tight” with the first list as the last item. The first time I encountered this I was very confused.
This example is closely related to Move Line Up/Down should respect list structure and empty-line groups which also deals with the new logic “ignoring” or skipping blank lines. Very counter-intuitive to me.
Proposed solution
As stated in the title I strongly feel that the new movement logic should be split to a separate option from the general “Smart lists”. I still want the functionality of creating new bullets/checkboxes automatically and new lines to be indented but I really struggle with and have to fight the movement logic.
A potential alternative solution would be to separate the shortcut commands into 2 different options. A “Smart move line up/down” and a “Move single line up/down”. The first would have the new behavior and move whole items in lists and the second would be the old behavior of the more “code oriented” literally “move a single line”. This is how the Line Mover extension seems to split them.
Also related Moving items up or down does not work correctly and Did "Move line up/down" behavior change something and how to bring it back?
I originally tried to post this in Move Line Up/Down should respect list structure and empty-line groups - #3 as the solution is likely the same but was told I should open a separate thread
