Use case or problem
When moving the cursor in the current live preview expanding and collapsing markups like **bold** is disrupting.
Add visual mode in which formatted text is only visible (WYSIWYG). Adding new markdowns would happen using shortcuts like in other visual editors (OneNote).
Markdown would only be visible when switching to a different mode or as a storage format.
Showing the markdown on cursor focus and not hiding the markdown is an amazing feature. Many many editors with “markdown” support screw this up. (confluence, google docs).
I can see some people would prefer what you describe. But for many of us, that is not an upgrade.
I would continue to mainly use Live Preview as it currently is. But if this feature existed, in the occasional cases where all the hashtags, equals signs, asterisks, etc. begin distracting from the ability to achieve a certain look quickly, I could just temporarily pop into this sub mode without leaving Live Preview. Once everything looked right, it could be easily toggled back off.
The mode you are describing sounds a lot like the existing Preview. As far as right look, there just isn’t a whole lot to markdown, by design. How would making bold/italic/heading changes work in this non-markdown edit mode and how would that be better that just editing the markdown? If you prefer to click a button for bold/italic instead of type
* there are some plugins for that.
I would imagine that there would be no Markdown visible even on the active line. I also think that if you selected a character or characters, there would be a pressed and unpressed state for the various formatting buttons that would make it clear what formatting is currently applied to the selection, giving you the option to easily zero it all out and start anew. Most users might continue to use the custom hotkeys they have set for the formatting operations but wouldn’t have to contend with the symbols in the occasional cases where they wanted to use this sub-mode.
Not sure this is exactly how @krzykot sees it but I am just guessing. Thanks.
Yes, something like a toolbar with formattings would be useful but I thought mainly about hotkeys.
I use Vim mode. When I move between words using
b (the same thing with Option+Arrow keys), the markdown expansion is a bit annoying because I need to move the cursor more times than in a visual editor.
I guess it would be a big effort but maybe it would also make Obsidian more approachable for beginners. In general I love Obsidian and it is minor thing.
@kryzkot you can use
B instead of
b to move by word, end-of-word, and beginning of word where special characters (including all markdown formatting characters) as part of any word they’re connected to.
Hello **this** is a test
2w and you get here:
Hello **this** is a test
2W and you get where you’d expect:
Hello **this** is a test
I personally think that the forced markdown syntax over a true WYSIWYG is a strength of Obsidian. Yes, it does mean a higher learning curve for some users, but the benefit it brings is the separation of content+structure (the markdown) and form (the appearance/style). The existance of an optional fully WYSIWYG mode blurs that line in a way that live preview doesn’t, which I think is bad for the notetakers who use Obsidian even if it means a higher initial cost to learn the app for some.
You are right that Live Preview means hidden characters that you don’t really account for when inputting vim commands. However, I’ve found that just setting default editor mode to Source Mode instead of Live Preview sufficiently solves this problem—when I’m editing, all the formatting marks are visible, giving me what feels like more direct control over them.
I understand if this doesn’t end up being a good solution for you, but I urge you to consider that using plaintext formatting marks makes vim more powerful, not less.
In order to get a fully WYSIWYG you can disable markdown “clutter” using this css :
Moreover, some plugins allow to fully set shortcuts for markdown, Format Hotkeys is an example.
+100 to this idea!
I know this will likely never happen but this is honestly what I was hoping the Live Preview feature was going to be.
There’s something about the visual disruption when going from preview to edit that I personally find very distracting, especially with links. If there’s anything that will ultimately take me away from Obsidian it’s this and the lack of robust outliner support.
There are many editors that have figured out how to do this that support using markdown add formatting and then use a combination of keyboard shortcuts and toolbars to edit.
Using the css snippet from @Mara-Li is unusable as it remove bullets points, etc…
tbh i don’t check the snippet in all details, but Im pretty sure you can create a snippet to select only the clutter you want
I would already be happy, if even the current live preview rendered everything correctly.
Codeblocks in list views are still completly broken, you cannot enter a new line with “shift+enter” in list view to create a new line but NOT a new bullet point (there is no desinction between new line and new paragraph) and all kinds of minor issues.
Since resources are limited for everyone (developers, plugin-developers, theme creators) the logic thing would be to only have two modes: source view and (a real) WYSIWYG editor.
But yeah, I support the idea to focus more on the WYSIWYG part.
@Craftidore I fail to see how pure markdown is “better for users” vs markdown hidden behind WYSIWYG. The document is still markdown formatted, markdown tokens are simply not shown or searched.
Assuming that people want or need markdown tokens to take effective notes is either gatekeeping, or beating down the request because you think it’s not worth the time developing.
That said, make “Reading Mode” writable with a toggle, add a cMenu-like ribbon and you’ve got full WYSIWYG. There’s no need for a new mode, at least UX wise.
For me live preview is an undesirable “hybrid” who shows its real problems in codeblocks, callouts, tables : everytime where the markdown syntax is too different from the visual result and wild visual jumping happens when switching between the two modes. Using a code editor (codemirror) as a backend, enforcing a “one-liner” paradigm that doesn’t play so well for a text editor versus the sister project prosemirror more document oriented and wysiwyg by nature.
I’m all in for a fully visual experience if it gets table support and no jittering in quotes, codeblocks etc ! It’s all about front-end anyway, it will get parsed and turned into the exact same markdown and markdown files, so nothing is lost
Thank you @Craftidore I didn’t know about W, E, B. I will try editing in source mode or experiment with some remapping.
I would also love to see a pure WYSIWYG mode - not a replacement, but as a base feature. I’ve personally gotten used to most of the markdown stuff I need to to know make it all work, but I quickly end up having so many hotkeys to use that I need to print out a dang list and keep it near at hand to remember (lol). It would be lovely to have it all just handled by the program.
I too would also love to see a pure WYSIWYG mode. I teach beginner college students and learning Markdown is not helping them embrace the idea of note taking/linking.
I agree completely. In Live Preview as it exists now, being able to see the markdown characters when the cursor is adjacent to them—which makes it easy to troubleshoot typos in the formatting—and hiding them otherwise creates the perfect balance between functionality and aesthetics.
And those who don’t want to type markdown characters can still use standard keyboard shortcuts like cmd/ctrl-i/b or a plugin like cMenu.
There are plenty of WYSIWYG programs out there. The power of Obsidian is that it is a plain text editor. It does use Markdown for some improved presentation, but at its heart it is plain text, which is useable across multiple platforms and should be useable in many programs for many years.