I believe command
insertNewlineContinueMarkup has a bug.
Apply markdown langauge
Place your keyboard cursor between
insertNewlineContinueMarkup. If you’re using default Markdown keybinding its probably “Enter”.
You will see this result:
There is no longer Point
1., there is no new
2., and the cursor is at the start of the first line.
What would you expect to happen, precisely? Just renumber 3. to 1., or create an empty 2.? How about if the cursor were at the start of
DEF, would you expect it to exit the list then or create a new item?
I’ll use character
| to mean “cursor”, the keyboard cursor.
I think, with this
when I run
insertNewlineContinueMarkup, which in 99.9999% of cases, will be
Enter key, I think this should be the result
Answering your question, if the cursor were at the start of
the command should do:
in my opinion.
Certainly it shouldn’t remove
1., or any list point.
In my opinion it’s the most intuivive way for it to work, and also IDEs like IntelliJ or WebStorm work like that.
To piggyback on this issue, since it may be quicker to address both of these at once:
I would also prefer that the cursor not go forwards when pressing backspace. It does when I hit enter, creating a new line, and then decide to get rid of it. I’ll also use the pipe character to show the cursor position.
Then I hit enter and it does this:
I hit backspace and it just deletes the space:
I hit backspace a second time, and now it replaces the whole
2. with spaces, including the space that I deleted, causing the cursor to jump forward:
Finally I hit backspace again and it deletes the three spaces, and I hit it again and it deletes the newline.
A: When I hit backspace the first time, replace all three in
2. with spaces. This reduces the number of times I need to hit backspace and keeps the cursor from going forward.
B: When I hit backspace the first time, delete all three characters. This would make hitting enter and backspace an alternative to hitting shift enter. Possibly make it so shift enter keeps the indentation but doesn’t add a new number. Currently shift-enter breaks out of the list.
BTW I appreciate that it’s simple for a developer to change this behavior without having to patch the library!
@Danon It seems the old behavior was intentional (there was a test checking it), but I guess that on second thought I also prefer the behavior your describe. Implemented in this patch.
@benatkin Piggybacking on vaguely related threads is generally not a great idea for clarity—next time, I’d prefer a separate thread. The thing you describe seems to have been unintentional, and was fixed in this patch.
Thanks for noticing!
@marijn Thanks for the quick update!
But there’s a space missing, for some reason.
1. |ABC\n2. DEF, and you press enter:
- you get
1.\n2. |ABC\n2. DEF
- instead of
1. \n2. |ABC\n2. DEF.
It’s not really an issue for me, but it feels wierd to me that if you put cursor after an item, press enter and create a new item, you get
space). Buf if you put cursor between
x. and an item, and the newly created item above doesn’t have the space.
Shouldn’t it either have spaces both times, or not have spaces both times?
@marijn I think there’s another type of bug in the markdown command. Currently, whe you have this state
(pipe is the cursor), and you invoke
insertNewlineContinueMarkup command, the
1. is removed
What I expect to happen is to get another list item:
PS: Altough now I noticed that’s how Github and IntelliJ work. So maybe that’s fine?
Yes, this is definitely intentional—pressing enter provides a quick way to exit the list.