Visual editing (WYSIWYG)

Press ESC and formatting will be applied, so the link will become clickable!

2 cents drop.

  • I like markdown but besides the bullet point * I mostly write it using keyboard shortcuts where supported. So ctrl b for bold in Dynalist or Reddit Enhanced Suite.
    • So, it you want to switch MD to WYSIWYG – no problem. Same keyboard shortcuts, same result :wink:
  • I love markdown in txt files; styling information in plain text.
    • so…if you do go WYSIWYG 100%, then export to MD should be an option
1 Like

the pro-markdown camp Image result for matrix all i see is blonde

1 Like

I would be hugely disappointed if markdown is removed for any reason.

It is one of the key features I look for in any text-based app, and it was instrumental in deciding to go with Dynalist.

If it is removed or delegated to second-class status, well :frowning:.

1 Like

@Erica Two years later :slight_smile:

Curious if the biggest blockers right now is “Uncertain reward: Not sure of what design to go with” or “High costs: This would take months to build that could go to adding more features.”

Something I’m wondering about, and you might know the answer: As Dynalist continues to grow its feature palette, will this transition only become harder? Because more code will need to be refactored.

I’ve been using at work lately and they have an interesting Markdown implementation.

What they do is apply the formatting as soon as the Markdown sequence happens. So if I type a dash followed by a space it switches into bullet mode; a hash and a space it becomes a level 1 header. Subsequently all editing is done WYSIWYG, using the toolbar or keyboard short-cuts.

So initial entry is very efficient and I can get the basic formatting in place. Then when I go back and edit I’m already working at a different pace, so mousing to a toolbar or using key-combination short-cuts isn’t the interruption it is when brainstorming.

Not everything is supported and not everything applies, so Dynalist would still have some work to (for bold, italic, and strike), but it’s pretty good:

Being able to start a line with [] space and [x] space to make an item a checklist would be an awesome addition to Dynalist too!!! Similarly starting a line with 1 period space to switch to numbered list mode would be so cool!

1 Like


I believe the WYSIWYG is related to the “Toggle plain text/rendered/normal” also at Trello, although separated.

I’ve got an idea, that probably has nothing to do with any of the topics, but I think that could be interesting. Forgive me if someone has already mentioned or commented about it before.

So, what if you implemented the same Padlock that we already on the Mobile versions onto the Web version? So, it could allow us to easily lock the edit and avoid the Markdown to be expanded (but still keeping the link active and working if clicked; the same behavior as we have in the Mobile UX/UI). That could be the easiest solution, IMO. I really like the Padlock on mobile. And I miss it a bit on the web (don’t use the Desktop app though). Having a shortcut to toggle lock/unlock would be nice as well.

I’ve switched from WorkFlowy recently and have been enjoying a lot the Dynalist world! Thanks for listening and for the great service you offer!


I second the notion of keeping the padlock in desktop mode. It’s useful on desktop when I’m referring to a document but don’t plan to edit it – especially when trying to copy text from code blocks.



What’s your guy’s general “potential-implementation-stance” on this at the moment?

  • Not Likely?
  • Possible?
  • Probable?
  • Definite?

Just trying to figure out if I should get my hopes up or not.


1 Like

Probable. Sorry about the late reply!

Having just started exploring Dynalist, part of the draw being some pseudo-minimal-markdown-like support, and already having mentioned/suggested Typora in a couple of other threads, seeing a mod saying “We prefer the Typora way” is really encouraging, Typora is truly awesome. My suggestion would be to work with them directly if that is feasible and an option.

That said: “we have mixed feelings about Markdown. It’s nice for the writers, but not nice for the programmers.” is perplexing, because the amount of already-existing markdown editing and rendering libraries is huge. Sure, integrating into the outlining structure might be tricky in parts, but the actual markdown stuff should be off-the-shelf I’d’ve thunk?

EDIT: Just having read a chunk more of this thread, I’m a bit perplexed by the extent of the passion for Dynalist’s current markdown support. I am a complete Dynalist noob, so might well have missed some enhanced paragraph editing tool, but AFAICT Dynalink supports headings (yay) at 3 levels, but does NOT e.g. recognise ‘## Heading’ as a level-2 heading. My hope is that whatever the WYSIWYG resolution is, it limits to the same ‘style-space’ as Markdown, and simultaneously brings with it more complete markdown support. [Again, caveated by the fact I might have not found some more complete markdown environment within Dynalist]

EDIT2: “if Typora were to open source their editor someday” Is Dynalist open source then? If so I did not realise. Still worth reaching out to them perhaps…

We do not use an existing Markdown parser. For example, the date syntax in Dynalist is only available in Dynalist, certainly, no Markdown parser on the market would do that out of the box. And I don’t mean that it’s not doable, it’s just painful/inelegant for a programmer to implement (not to use). Markdown is just a non-machine friendly language specification. The advantage, of course, is that it’s super friendly to humans.

No, Dynalist is closed-sourced. It’s been a long time (the part you quoted me was from 2.5 years ago), but I think I meant if Typera were to open source their editor, us using their rendering engine might be an improvement over what Dynalist had at that moment.

It has been a long time since the start of the thread, and lots of things, both about Dynalist and about Typora, has changed. So lots of discussions might be perplexing… sorry about that.

1 Like

Indeed, totally - although there are several efforts to try and refine and resolve that somewhat. But that’s kind of what I mean - other people have already dealt with this (to at least a large extent) so using a third party Markdown parser/renderer both takes the load off in terms of working out how to deal with mismatched or intermingled asterisks and underscores and things like that, and simultaneously potentially provides supports for tables and code-snippet syntax-highlighting and a bunch of other text-feature stuff at the same time.

No worries - as I have been working through the forums I am massively impressed by the community support, and the responsiveness and attentiveness. Hence the motivation to take the time and give input here and there. [EDIT: Although I confess to not looking at the posting dates!]

Just to add to what @Erica said. We must implement our own Markdown parser/renderer for a couple of reasons:

  • Dynalist has our own flavor of Markdown, to support things like Date/Reminders, LaTeX, etc.
  • Dynalist ONLY supports inline Markdown, and does not support any document level (things like making a markdown bullet list, paragraphs, etc). So those won’t be necessary (and also must be disabled).
  • Each Dynalist item has its own editing box, and each “note” has its own editing box as well. For performance reasons, we can’t really turn every editing box into a 3rd party markdown editor, because that would end up with potentially thousands of instances. Dynalist with our feature-rich formats is already taking a toll on performance compared to competing products, and this would make the problem even worse.
  • There are many many things that will need interfacing with a 3rd party editor system, that we need to take over and write ourselves anyway. This would almost defeat the purpose of using one.
    • Undo/Redo across the whole document, not just within an item’s editor box.
    • Saving selection positions (for example, if you “Undo”, we’ll put your cursor at the position that was undone).
    • Implementing custom boxes with custom behavior would be a big pain (date/reminders, LaTeX, etc).
    • Debugging 3rd party code, tweaking the internals for our purposes, and end up having to maintain it ourselves anyway.