Made an account to add to this FR. The landing page for Obsidian says: “Obsidian is the private and flexible writing app that adapts to the way you think.”. There’s a lot of discontent with this forced feature migration, please allow the users that do not want the new table editor to opt out of it
3 Likes
This table behavior does not match the behavior of WYSIWYG editing with other content, such as YAML, source code blocks, markdown headers and other markdown formatting. If my cursor enters something with a rich view, I want to be editing the source code behind that view. Learning a new set of keybinds is not something I’m going to do here. I’m going to open my folders full of markdown in VSCode and resolve the pain point. Please rethink this.
1 Like
+1 for this FR
The new table rendering breaks basic markdown syntax and vim functionality. This definitely raises the friction to write tables in Obsidian.
I personally haven’t written any notes with tables in Live Preview Mode since the new update. As a workarround I’ve been using AidenLx’s excellent Table-Extended Plugin.
Considering that Tables are such a core markdown feature it’s important that one can still use the standard markdown syntax in Live Preview mode if needed. For this reason I also suggest adding the new Live Preview Table Rendering as a Core Plugin thus giving the user the freedom to toggle this feature on or off.
As a sidenote I think the old Advanced-Tables Plugin is still valuable to many people. If the user can toggle this feature off they would also be able to revert back to the Advanced-Tables Plugin which had an intuitive design and was still compatible with the vi keybindings.
1 Like
I hope this is getting traction. The breaking of vim keybindings has been hard to deal with
2 Likes
I consider this a bug or regression rather than a feature request. Maybe the label could use an adjustment…
3 Likes
I’ve opened a bug report here Table editing doesn't revert to source code mode when my cursor enters the preview
3 Likes
It’s frustrating to be pointed back to this conversation by a member of the Obsidian team with “we understand”. This change was not consistent with other feature additions to Obsidian. It doesn’t even leave room for plugins to replace the new behavior. The more features get added to Obsidian that don’t include the power of the Obsidian design ethos, the further this will push users away. Right now it may only sound like vim users being annoyed, but your initial design is slipping away while you are prioritizing feature delivery
4 Likes
Adding to this conversation as it is really frustrating. Overall it feels buggy. Every time I create a new table I manually need to set the alignment with my mouse which before was easily done by writing.
Additionally I experienced a bug where copy/pasting values and then reverting them removing parts of other cells. Although I was not able to reproduce this again.
Please please disable the Live View of the tables.
1 Like
+1 for some way to edit tables more conveniently. Even after switching to source mode, i find it hard to navigate and edit the table contents.
Thanks!
Shaiya
1 Like
this is still a pain to use any hasn’t been addressed by the obsidian team 
+1 I really want this to be toggleable
I was very surprised that this wasn’t a part of the new feature.
+1 to the ability to disable the new table editing feature because of it breaking VIM keybindings. I also signed up for these forms just to voice my displeasure with how VIM style navigation is broken with the table update.
I noticed that since there has to be a line between the text above a table and the table for markdown to recognize the table, so I thought a workaround would be to remove the line. However, the new table editing feature prevents me from removing that line. I literally had to remove both the line and table header (d2j) to remove it. In my opinion, the fact that there is no way to disable this feature alone makes it a bad feature. I understand that many may appreciate the safeguards and similarity to other table editing tools, for me though it severely limits what I am able to do.
Welp, it is lovely to know that the exact workaround I was trying worked at one point in time.
For those looking through this thread having similar issues to everyone here, this workaround no longer works. If you add a character in the line immediately preceding the table a new line is added directly after the character just added, and this line can’t be deleted without also deleting part of the table (the similar workaround I was trying).