Buggy bullet point behavior when cutting a list in half

Beta Beta Bug Reports
1

Testing version:
Version 2.0 (10936)

What were you doing:
Have a list and split it in half, trying to remove the tab or bullet point behavis weirdly. See the video.

What happened:

What did you expect to happen:
I expected that the deleted bullet point is reverted to regular text which is not indented from the left.

1 Like
2

Hello, please take a look at this post:

Double enter does not exit list mode

According to the definition it works if you press ENTER three times and then BACK-DEL “<–” once. This deletes the second empty line and you can continue writing norally. The first empty line is then part of the last element of the list. It worked for me.

It is a little tricky and you have to get used to it. Maybe this helps.

3

That’s not a good answer answer. If I do what you say, it indents the text correctly, but it’s still buggy behavior.

4

I completely understand the behavior is not intuitive to everyone, and absolutely get the feeling when you feel the behavior isn’t predictive and things seem out of control.

Assuming I correctly understand what you would like to achieve: to split a list into two half and insert some text between the resulting two lists, as normal, unindented text, here’s what you could do:

It’s easier to have some example to illustrate, so let’s have this example text to work with and the goal is to split between P2 and P3 bullets.

- P1
- P2
- P3
- P4

Method 1

  1. Place the cursor to the end of P2
  2. Press enter once
    • The cursor is now at the line below P2 and considered still part of that bullet, and hence the cursor is placed indented.
    • If you start typing, it will remain indented. If you manually place the cursor to the unindented position (i.e., beginning of the line) and start typing, it will automatically indent the text, as it is still part of the bullet.
  3. Press enter again
    • Now this line is not part of the previous paragraph (and hence not a bullet from a list anymore).
    • Notice that the cursor is still indented, which I found weird, and maybe this is what you meant to be buggy?
  4. But you could actually just type even when the cursor is placed at the indented location. The resulting rendering actually is correct: normal text is produced, unindented.

So while pressing enter three times followed by a backspace works, it isn’t required nor the only way achieving the goal. However, I do not understand why the cursor is placed indented after two returns (i.e., after step 3).

Method 2

  1. Place your cursor at the very beginning of the line for P3.
  2. Press enter twice. (This creates two lines above P3. The upper serves as a paragraph break, and the lower would be the new empty line where you can add the normal text.)
  3. Place the cursor at the beginning of the line immediately before P3 and start typing.
    • Note that, even if you place the cursor at the indented position, as soon as you start typing, the text will start from the beginning of the line and thus unindented. This also is a correct rendering based on the markdown syntax.
1 Like
5

Thanks for the detailed, but very complicated reply. I had to find time to test this.

Method 2 feels totally unintuitive for me - I need to navigate to the list before which I want to add content. Feel strange. Plus I go to P3, then create two lines before it and then start typing in the second line. Down-up-up-down, I’m getting dizzy.

Method 1 works but as you correctly pointed out, there is that bug(?) in step 3 when the new line appears indented but when I actually type, all works fine. I consider this truly a bug and I’m hesitant to type when the cursor looks off. With this bug resolved, I think the behavior would actually make sense as is.

1 Like
6

Yes I agree - that really seems like a bug. And the dev team mentioned that they would look into this from another thread related to indentation behaviors. Hopefully it gets fixed soon :crossed_fingers:

1 Like