Hi! The new table display looks cool, but it’s interfering with a lot of my vim workflows for navigating and editing the table. For example, doing 5k no longer goes up 5 lines, the cursor just stays there. Are there plans to fix this?
Alternatively, can I disable this UI?
move to help
You can switch to Source Mode (via command palette or the “…” menu).
Hi! I am having the same issue for vim workflow, being able to use only keyboard for table is a big plus for me.
After the updates, I am experiencing these problems:
‘dd’ no longer deletes a row.
‘o’ is creating a new line in the same table cell.
It’s harder to navigate, is there a plan to fix this in the future release other than resorting to Source Mode? (I’d prefer to not use table at all in this case…)
Much appreciate your updates in advance.
renamed and moved to feature requests
Hi everyone! Just to say I’m having a similar issue and miss being able to easily copy/paste/insert/delete rows from tables via VIM bindings. the main commands I use a lot (similar to the above folks) are ‘y’ to copy a row, ‘dd’ to delete & copy, ‘p’ to paste an entire new row, and ‘o’ to open a new row.
Thanks to @CawlinTeffid for the reminder about source mode. That’s a helpful work-around until more complete VIM support can be restored.
Make no mistake: the new table features are indeed very cool (can we get column sorting next?)
It’ll be really great when we can use the ol’ VIM bindings the same way again.
Thanks for keeping Obsidian awesome
Same issue here: vim bindings were lost for the tables. dd
and o
as noted above, and I’ve also seen .
(repeat previous command) is not working as well.
This is a huge deal for me: I live in vim as a software developer, and “vim in obsidian” is what made Obsidian the right choice for me. I accepted the fact that I couldn’t migrate my macros and such, but fundamental vim is a must have… and dd,
o,
.` are about as fundamental as it gets.
Now that the team has started breaking the most basic of vim commands, I wonder what the next step will be? Is it really to be “Yes, vim, until we decide it’s not?”
Why is basic vim that used to work and now is broken a “feature request”?
And dd
is not a navigation command… it’s basic editing.
renamed again for clarity.
Live Preview Tables is a new feature and doesn’t fully work with vim yet.
There was no real editing of tables in live preview. It was just a matter of flipping from the raw markdown to the rendered view of the whole table (and viceversa). This was a major pain point for a vast chunk of our userbase.
You can always use source mode if you want a vim experience.
First off, thanks for clarifying the request. That helps.
Hmm… I think I’ve been using live preview for quite a while, but when in tables, it used to switch… to what looked like markdown, so I guess that’s what you’re calling “source mode”. OK. I get that the new approach is easier for non-vim folks. It was just a shock to me.
I do hope this is not the beginning of making Vim a second-class citizen. Having to remember “parts of Vim don’t work here” would make things frustrating.
It’s been absolutely wonderful having a real word-processing program that speaks Vim.
This explains Obsidian’s views and modes: Edit and preview Markdown - Obsidian Help
Thanks for all the feedbacks.
I talked to the discord mod about this a month back before my comments and he clearly suggested this was a bug.
I agree with @jesii7 100%.
Obviously there was real VIM editing of tables in live preview before the new table were introduced, now I am stuck between the following options:
- abandon VIM flow completely to use new table in live preview
- abandon live preview completely to use VIM flow with source code table (plain md)
- abandon table completely to use VIM and live preview, but my old notes are rendered unmodifiable unless I switch to source mode.
(Personally I choose number 3)
Either way this is clearly counter productive and obsidian should provide some backward compatibility when they introduce the new table, mainly
a button to select new/old table in live preview.
There is a feature request for this already, you can add your voice to it.
Here are some additional limitations I’m running into that haven’t been mentioned:
Pressing ‘w’ and ‘b’ does not move to the cursor the next / previous column (even though ‘l’ and ‘h’ do).
Selection started with ‘v’ or ‘shift+v’ get canceled once you move to a different cell. It would be nice to be able to select multiple rows in line select mode, or multiple cells with normal select mode.
I do think Live Preview Tables are awesome, even with the current Vim limitations.
Steps to reproduce
- Open the sandbox vault.
- Insert a table in any note.
- Add some text to the first cell of the table.
- Go to the settings and enable vim key bindings.
- In normal mode with the cursor on the last character of the text in the first cell, press
x
.
Did you follow the troubleshooting guide? [Y/N]
Y
Expected result
The last character in the cell should be deleted and the cursor should move the blank position beyond it, as if you had pressed h
when in the next cell.
Actual result
The character is not deleted and the cursor moves to the next cell.
Environment
SYSTEM INFO:
Obsidian version: v1.5.3
Installer version: v1.4.13
Operating system: Windows 10 Home 10.0.19045
Login status: not logged in
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on
RECOMMENDATIONS:
none
I don’t know how to keep this alive without a useless comment like the one I’m writing now. My reply does not improve the conversation, but I don’t think this should close just because there’s no conversation left to have about it.
This topic will close 3 months after the last reply.
For some reason there was a timer associated with this thread. I removed it now.
Plus one. The three options from levibbq are spot on and what I experience as well since the update. If I am in a table, I’m stuck, I can’t get out without clicking and using the mouse, scrolling and clicking outside the table to navigate back with vim. If my scroll accidentally lands in the table, I can’t navigate anymore. Big issue for me too.
I have specifically registered the account to reply to this post. Really hoping the dev team can solve the problem.
Issues I encounter with vim mode and tables (first mentioned here)
- On a table with 1 line per row, pressing
5j
does not in fact go down 5 rows. It goes down 5 rows in the cell that it’s in, and then jumps down 1 row. - When scrolling through a document with
<C-d>
and<C-u>
, passing a table messes up the whole scrolling flow. If you end up with the cursor inside of the table, then you have to hit a<C-d>
or<C-u>
to scroll down/up one row at a time. This is very annoying. - In a cell which has lines wrapped, I can not for example move down a visual line with
gj
. Have to scroll “to the right” until I get to the next visual line in the cell. - Every cell is its own “document” so it has its own line numbers, which doesn’t make a lot of sense. When displaying line numbers, now I’m on “line 1” wherever I am at in the table. With relative line numbers this is especially painful, I can see that I am 7 lines into the table, but I can not jump 7 lines up. (This is when using the relative line numbers plugin – in the sandbox vault it doesn’t show a line number inside of the cell – maybe that’s a bug I should report on the relative line numbers repo).