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:.


@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.

To me the argument for markdown is more about portability of my data, and less about the editing experience. What I don’t like about a pure WYSIWYG editor is it makes it much easier to add data to my lists that will be harder to export, or be interpreted by other software. As other’s have mentioned there are a ton of tools for converting markdown into other formats. Even if Dynalist uses some custom Markdown formatting for not standard elements like dates, they are still human readable text that could easily be modify later with basic find/replace/regex tools.

Also, with markdown it’s also easy to see exactly what information is included, and well as not included. I hate exporting from one software file format to another, and never being 100% sure if all my data was move from one format to the other.


today is 2020-02-01, will this feature release soon?:grin:

1 Like

I very much worry about the release of this feature. I hope it will be purely optional, allowing those of us who prefer to stick with plain-text and Markdown, to be able to do so indefinitely.

I have seen many pieces of software destroyed by the introduction of supposedly “advanced features” that were not strictly necessary. A huge chunk of developer resources went that way, with little profit eventually.

I hope this will not happen to Dynalist.


Yes so for those wondering about how this is going - It’s still in the pipeline but we anticipate it’s going to take a long time before it’s production ready.

To address the concerns people have, it will be optional, and perhaps enabled by default for new users. Our current plan is to store the data in markdown format as it is right now, and the WYSIWYG editor is a pure augmentation that works on top of the markdown format.

In terms of development cycle, we developed a separate proof-of-concept to test the waters with current browser technology and it’s mostly working. The difficulty right now lies mostly on merging that into current Dynalist, all without interfering with the regular editor mode that we currently have. The other big project that affects development is a big code cleanup of the editor (which was mostly developed around 2015-2016). Given our current experience with Dynalist, there are many previous design decisions that we think could use some improvement and rethinking. This will give our new WYSIWYG editor a better base to work on, which means we won’t need to write hacky code to make it work, less chance of bugs, and easier to maintain in the future.

We’re doing this slowly and cautiously, given that we’ve seen some examples of how NOT to do WYSIWYG (see Slack). We’re also still spending a significant amount of time improving Dynalist in other ways: fixing bugs and developing other highly requested functionality unrelated to WYSIWYG. This is more of a long term project that we primarily see as making Dynalist more friendly to users (especially new users) who are less familiar with Markdown.


To add to Shida’s reply, here are some things we’ve been up to in parallel with WYSIWYG:


“To address the concerns people have, it will be optional, and perhaps enabled by default for new users. Our current plan is to store the data in markdown format as it is right now, and the WYSIWYG editor is a pure augmentation that works on top of the markdown format.”

Sigh if relief

Although I expected as much. It’s nice to hear you say it.