When using Vim key bindings, pressing o or O (open new line) in Normal mode doesn’t behave the same way Enter does in Insert mode, as it doesn’t seem aware of the current Markdown context.
For example, unlike Enter, o/O does not:
create a new list item when used within a list
retain indentation level when used within a code block
continue a blockquote
In other words, the new line should ideally be a part of the list/blockquote, ie. be prefixed with - , > or similar, just like if you had pressed Enter in insert mode (or non-Vim mode).
Proposed solution
Make Vim mode respect the current Markdown context.
Current workaround (optional)
I usually press a (append to line) and then Enter, but I just as often forget to do it, so I press o and then Backspace followed by Enter.
Yes please!! I’m constantly writing outlines or taking notes and almost every time I need to create a new line I press o. Then I have to delete the whole line (often including a few space characters at the beginning of the line for some reason), move the cursor back to the end of the previous line, enter insert mode, and then press enter.
This isn’t a muscle memory I’m going to lose given how often I use it in vim, vscode, and other places and it really interrupts the flow.
Adding to the list of things o doesn’t account for:
adding a new row in the advanced tables plugin
It would probably make things a lot more consistent for o to just be a macro for “move the cursor to the end of the line in insert mode and press enter”, or “A + enter”, so that any plugins rebinding enter for a particular context are still respected by vim mode.
As a temporary workaround in case this doesn’t get addressed: There is a “Vimrc Support” plugin that lets you do custom mappings. I haven’t tested it. But I wonder if you could remap o to <esc>A<enter> or equivalent. O might be trickier.
That’d be a nice solution, but I can’t get it to work. I try the following mappings:
map o <Esc>A<CR>
map O <Esc>I<CR><Esc>ki
And the mappings are applied, but the carriage returns don’t seem to work. o works the same as A on its own, and O the same as I<Esc>ki.
The first thing I thought was that maybe <CR> is called something else here, or just isn’t supported, but it works on its own in other mappings (I tried to bind the unused + key to just <CR>, for example, which worked).
Note that you can test these mappings in Obsidian without Vimrc Support, by hitting : in Normal mode followed by the map command.
There’s a workaround @pseudometa found (requires the vimrc plugin).
btw, the last update for the code editor shortcuts plugin enables us to create a better o and O in Obsidian that properly inserts prefixes for markdown lists
" Smarter o and O (inserting prefix for markdown lists)
exmap blankBelow obcommand obsidian-editor-shortcuts:insertLineBelow
exmap blankAbove obcommand obsidian-editor-shortcuts:insertLineAbove
nmap &a& :blankAbove
nmap &b& :blankBelow
nmap o &b&i
nmap O &a&i
One little thing I noticed: It doesn’t recognize checkboxes (ie. - [ ]) as a leading list prefix, it just continues a checkbox list as a regular bullet list. Not a big deal, but a bit annoying.
When I’m inside of some list and press ‘o’ in vim normal mode, I expected to have a new list item created below, just like when hitting ‘Enter’ creates a new list item. Instead ‘o’ creates a new blank line. Similarly with ‘O’.
Another thing that would be neat (but it’s less essential), is when some list item has children which are folded, hitting ‘o’ should intuitively create a new item after all those children, without unfolding. Instead it has a really strange behavior, where the ‘…’ indicator gets moved to the new line, so this folded item gets broken.
There are probably more vim commands that could be adapted to lists, like ‘cc’ but they are less important.
Proposed solution
Current workaround (optional)
I tried to remap:
:nmap o A<Enter>
but it turns out that obsidian doesn’t handle this remapping well - when I hit ‘o’, only ‘A’ gets executed, and then <Enter> gets ignored. I tried it also with other things than <Enter>, but all of them get ignored, after ‘A’ already changed the mode to insert mode.
Tried the same thing, but seems like the blankAbove and blankBelow are not exported successfully, so it currently remaps o and O to i.
Any way to fix it?
Here is a solution which uses a minor workaround, since the vimrc plugin does not allow ex-commands to be mapped together with normal commands, but well, it does work.
Requires the vimrc plugin and the code editor shortcuts plugin. Copypaste the following into your obsidian.vimrc
" Make o and O respect context
exmap blankBelow obcommand obsidian-editor-shortcuts:insertLineBelow
exmap blankAbove obcommand obsidian-editor-shortcuts:insertLineAbove
nmap &a& :blankAbove
nmap &b& :blankBelow
nmap o &b&i
nmap O &a&i
When I write in obsidian using vim mode, the lists are really annoying to use. I’m not sure if this is a bug or a feature so I when conservative with feature request.
When I press enter in obsidian it automatically adds a new item to the list I am working on when I press enter (I use - lists which get converted to full dots).When I try to do the same thing with vim, by pressing o, it does not add a new item to the list. Very annoying, please fix / add
While in “normal” mode, if the cursor is at the end of the line that is an item of a markdown unordered list, using the o key inserts a newline but does not continue with a new item in the list. In “insert” mode, with the cursor in the same location, <cr> does create a new item on the next line with the cursor ready to enter the item.
Proposed solution
Update normal mode vim bindings for o key to work like <cr> in insert mode.
I was annoyed at this as well, but then I have several instances where I do want to start a new paragraph at the end of a list.
I’ll probably end up finding a mapping I like for “$” → “a” → “Enter” as this is my current solution when in visual mode at the end of a list I want to add to. Probably “ni” for new item or something like that.
My main point is, the Vim command “o” is behaving like I expect it to, and I think changing that expected behavior across the board for particular use cases will slowly break the Vim mode advantage.
@tobiasvl and @maddu and the other people that are experiencing this issue: What is your ‘Indent using tabs’ setting (Under ‘Editor’) set to?
I can replicate this erratic behaviour only when ‘Indent using tabs’ is active. The ‘Smart indent lists’ and ‘Tab indent size’ seem to have no effect on this.
When using tabs to indent I can indeed use the mentioned code editor shortcuts workaround, but it would be nice to get this fixed of course!