A WYSIWYM (Typora-like) editing mode

I know it’s on the roadmap but …
+1 for WYSIWYG :blush:
(with switch to code mode, if you need to arrange things behind the curtain)

NB: in my humble work of literary writing, and my passage from word processing to markdown (drafts and connective notes in light format (plain-text)), the difficult part was not learning mardown but the distraction side. The applications with two side-by-side panels (code and render) did not suit me at all. I really adopted markdown thanks to Typora, because the wysiwyg gives me a more direct experience of writing (strike out, highlight, etc., almost like on paper).

1 Like

Still Hope dev team could move this feature from Long-Term to Short-Term.

After the great ‘Block References’ feature, WYSIWYM becomes more urgent:

BTW: Drag-Drop to automatically create Block Reference like Roam would be great.


Agreed. It’s the one thing that keeps me from saying bye to Roam


@thinkertype: if that’s the only thing, right now you can get a pretty close approximation with “remove clutter” CSS. Add to that the same font for Edit and Preview and you’ll wonder why you waited :sweat_smile:

Thanks for the tip, let me check it out now.

@thinkertype: I collected all my CSS snippet in 1 file, and that includes the “Full Monty” on WYSIWYG.

+1 WYSIWYM,It’s my favorite function. Hope support soon.


Bingo. Totally with you. I don’t want to have to use my imagination to picture how… what I’m working on now, will look like later.

I want to see the finished product at all times—constantly. Anything else, is another “step” that adds time to the task I’m trying to do.

The “forced-viewing-of-markdown-syntax-while-editing” that so many notes apps force… on the user, is in my opinion, an epidemic. I don’t know why they do it.

When I select a word, then hit CMD+B to make that text I just selected bold, and am then presented with four asterisks… I feel like I’ve just been lied too.

Whoa, it looks like I have an opinion.


Because it’s easy for the programmer.

1 Like

Hey Alan,

Is it really? Aside from changing the look of existing apps with css, I can’t code at all. So really, I don’t know.

Your elaboration would help explain a common frustration I have.

Markdown is as easy as typing text. First a * then whatever then another *. Formatting stuff on the fly is a whole lot more intricate than that.

1 Like

+1 to this, would love to be able to render latex in edit mode

1 Like

+1 for prioritizing WYSIWYM over the mobile app :slight_smile:


Typora is indeed a great model to follow for UI.
I’m very much looking forward to hybrid editor - less mental bandwidth spent on multiple inputs, and allows you to focus on what you’re writing.

1 Like

@grub: it won’t be hybrid - see Licat’s comment.

Thanks - WYSIWYG mode will do me!


+1 for WYSIWYG mode sooner.

Thank you.

Support this feature. +1

I’m using a downloadable CSS snippet that removes much of the markdown from edit mode and presents lines pretty much as they will appear in preview mode. So bullets look like bullets, bold is bold, highlighted text is highlighted, tickboxes look like tickboxes, headers are underlined and the right size etc all without unsightly dashes, hashes underlines and equals signs scattered through the text. You only see the markdown when you click on a paragraph to edit it. When you click off the markdown symbols disappear.

This does have some clunky aspects though. When you click on a paragraph, because the CSS has moved things, the cursor doesn’t always end up where you expected. Also you can’t show images or tables yet.

If they could fix these couple of niggles I would be happy with this approach. I.e. you use markdown when you are clicked into a paragraph but it previews when you click off it. I’ve no idea if this would be harder or easier to implement than a full WYSIWYG editor that never shows markdown.

I would be quite happy with this implementation also, if it is much easier/faster to do than a full blown WYSIWYG.

One slight suggestion - to make the visual switch to Markdown on mouse over also, rather than just when the cursor is within the line. This would help avoid the problem of clicking in the wrong place.