`unmap <Space>` breaks `o` normal mode binding

[macintacos]

Please Review Before Posting!

- [ ] I checked that the bug does not happen in the CodeMirror Vim demo. If it does, please report it there and not here.
- [ ] I'm reasonably sure that this bug is indeed about the Vimrc file support and not a general Vim in Obsidian issue. If it's a general Vim issue, report it here.

The link to repl.co is broken, so I can't test it. Is there another way I can test this issue? I went here, and at least can confirm that when I run :unmap <Space>, o still works just as I would expect.

Also I'm not really sure what the deal is, as I can't tell if this is an issue with this plugin or the vim implementation itself.

Describe the bug:

In the README for this project, it says:

<Space> can be bound to make chords, such as <Space>fs in conjunction with obcommand to save your current file and more.
But first <Space> must be unbound with unmap <Space>.
Afterwards <Space> can be mapped normally as any other key.

I did this, and it seems to completely break o. I have only this in my .obsidian.vimrc and can still reproduce it:

unmap <Space>

Without it, o functions normally (goes to the next line, switches to insert mode). With it, o jumps to the end of the line, and then somehow the <space> key enters a literal space into the text, but it keeps me in normal mode somehow... it's a bit strange, frankly.

To Reproduce:

Steps to reproduce the behavior:

• Add unmap <Space> to your vimrc and then try to use o while editing text.

Environment (please complete the following information):

• OS: macOS 15.7.3
• Vimrc plugin version: 0.10.2

[macintacos]

Seems to be intermittent. It happens consistently when I'm on a line that is very long (meaning like, a paragraph), I'm at the beginning of the line, and I hit o.