Visual editing (WYSIWYG)


  • support a writer who is typing away in Markdown
  • support a novice user by also providing context menus for formatting and links
  • and for both users, Dynalist would be backing up plain text Markdown files to Dropbox, etc.
1 Like

Hm. Doesn’t a user who is typing away tend to use shortcuts anyway, which can either insert the markdown or change the formatting WYSIWYG-style?

I’m confused. Dynalist uses double marks, such as the double underscore and double asterisk, where other markdowns use singe marks or other conventions which mix single and double. Does this not cause trouble when trying to copy-paste from Dynalist to Reddit?

I totally believe that you two have reasons for preferring Markdown, I’m just not understanding what they are yet.

Dynalist isn’t a word processor. Nor do I think it should be. While short cut keys are acceptable for a few specific common functions like bold or italics I don’t know that, along with all the other shortcuts currently implemented, they should even try to create full shortcut mappings for every formatting option possible.

Ironic that you should mention those 4 markdown implementations, as not one of them implements markdown in the same way. Fact is, between extensions and no true markdown specification (only what the creator feels is a cannon implementation), there is no full agreement on the syntax. So every implementation has its own quirks and differences. See CommonMark for information on why they chose to try and create their own derivative.


Probably the best example of using markdown to use dynalist to brainstorm a topic (outlining), and then push it into whatever platform you want that supports markdown format

This way you can write summary reports quicker, blog posts, write a fiction novel, make a technical manual quicker, while still using dynalist is your main ecosystem.

While this is correct, there are common syntaxes between most markdown deriviatives. Bold is almost always ** bold **, italics are almost always * italics *. In any case, it doesn’t matter which variant you use (I like github or reddits version), since you can run it in

Yeah, that’s why we have mixed feelings about Markdown. It’s nice for the writers, but not nice for the programmers. It’s not a strict markdown language and it’s more human friendly than machine friendly, at least that’s how we feel about it :frowning:

Ulysses and Typora do no need to support custom objects like dates and internal links, it’s way easier for them to implement.

We prefer the Typora way. “The neat, tidy look of a bullet abruptly changes when inserting the cursor” This is true for Typora also, we’ve tried our best to position the cursor as the right spot as you see it, it used to be the same fixed position but wrong relative position (the cursor lands at where you click, but far away from where the character that you intended to click on).


Hi Abram,

Thanks for your note. My main reason for loving Markdown is that it is an excellent way to organize and format text documents. As a software developer, I do a lot of work in GitHub, Visual Studio Online, and other collaboration platforms. The teams I work with use Markdown as our common text format for documentation, instructions, reference, and even online discourse such as this forum. Because it’s plain text, it’s easy for both humans and computers to work with. It can be read by humans without special software, imported and transformed by computers, and easily version-controlled.

I also use Markdown in my personal note-taking, because it allows me to focus on the content of the text (e.g. headings, tables, and emphasis) without getting distracted by the appearance of the text (font family, size, margins, etc.). In graphical text editors such as Word, I sometimes get distracted by trying to make a document look perfect instead of finishing the content. Using Markdown helps me to focus instead on what needs to be communicated and leave the formatting to the many excellent tools available.

I don’t just write in Markdown, I think in it.

I love Dynalist because it not only gives me powerful tools for organizing my thoughts into a hierarchy, but also supports the formatting I use every day. I use Dynalist to organize my to-do lists, plan projects, draft documentation, compose messages, write prose, and a dozen other things – all using Markdown. And the best part is, when I need to export out these documents to GitHub, VSOL, Discourse, etc., it’s already in the format the target system wants, no conversion required.

So these are a few of the reasons I love Markdown. As you might guess, Dynalist’s support of Markdown is one of its most important features for me, and I’d be very sad to see it dropped. :slight_smile:


So many replies in this thread, did not have time to read all so apols if this has been covered. When WYSIWYG editing is implementeed, will this also cover the issue where clicking into a line makes the links / tags no longer clickable?

Sometimes my cursor is inside a line and I want to click the tag or link in that link… currently I can’t. Is this issue going to be fixed as part of this WYSIWYG update or is this a separate feature request?

@Daryl_Mander, DL’s management of URLs in notes is one of my top pain points vs. Workflowy. I’ve suggested by email (before I was aware of this forum) an improvement to show a launch icon next to URL, to allow best of both worlds for inline editing and launch. This reminds me I should open up a separate thread on that in Improvements area; will try to do this soon.

1 Like

Great points, @Craig_Oliver !

I think Markdown also encourages adopters that are familiar with Markdown, and feel like their notes aren’t lost to another proprietary system if they have the safety net of exporting everything as Markdown.

Others have mentioned Typora and Bear. Maybe a source mode, similar to Typora’s Source Code mode, that has predictable cursor behavior by keeping the markup in place and applying the styling once valid? And then a separate presentation mode for users that aren’t interested in Markdown syntax, with a medium-like menu.

Honestly, I think it may just be the psychology that Markdown is a simple, portable, human-readable format, more than wanting those shortcuts. It seems related to the growth of JSON over XML, even though JSON is lacking tons of features as a serialization format that are now being bolted on as JSON schema and such, it got mass adoption as a readable and comprehensible format that has a limited set of rules. It’s a gradual increase of complexity from visually organizing a simple text file with notes that are related as hierarchical bullets, to introducting a little more syntax for document linking, checkboxes, tags, etc., that have special and non-portable features attached to them.

It’s the convolusion of a set of community accepted behaviors that eventually trickle down to people that don’t care about syntax, but it’s so simple and distilled that the utility is obvious. Like “hash tagging,” that was possibly cemented for the general public by Twitter’s adoption? Now it’s used in Slack and Dynalist, and the syntax doesn’t create friction for general users since they’re already familiar.


This seems something like Whatsapp formatting which I really don’t mind.

This is quite true for me also. I love the idea of Markdown text but at the same time I hate when editing text and everything becomes jumbled all over in plain text.

I do like both ideas posted above, one being that the rendered and edited text show the Markdown in light grey, while keeping the formatting of the text…and I also like the idea where the user can pick a default (WYSIWYG or Markdown) and switch between modes.

1 Like

The main reason I’d prefer WYSIWYG is because I like my formatting to remain persistent when clicking through things, not switch from THIS to * * THIS * * when I select it, in particular if I have code snippets I want to copy out and paste into a command line. Just personal preference I guess.


Here are some pain points mentioned:

  • some people prefer Markdown, some people prefer WYSIWYG; the ideal solution is the one that combines both
  • converting between Markdown and WYSIWYG is highly nontrivial
  • Markdown is underspecified
  • WYSIWYG is also very nontrivial (ContentEditable is a massive PITA)
  • even with WYSIWYG the text must be stored in some form

There is a way to have them sorted: ProseMirror

  • it is a react/flux-inspired (that is, it separates state, updates it with incoming events and updates the representation) WYSIWYG over a structured text
  • it comes from an author of CodeMirror
  • that “structured text” is in fact just a collection of plain JS objects that is trivially encodeable in JSON and amenable to JSON schema
  • text is 100% specified by the state schema
  • one can have a schema that is renderable both as Markdown and as WYSIWYG, here is a demo
  • it has a very clear concurrency model/collaborative editing (because those “events” can be treated as “deltas”, transmitted over the network and applied independently)

It has some downsides:

  • it’s more complicated than other drop-in replacements (it’s more of a framework for editors than a ready-made editor)
  • it may be too expensive to have it on every line of the tree or enable it on click/focus

Thanks for the clear summary, and thanks for the pointer to ProseMirror. @Shida, could you please take a look?

Here are my thoughts:

This and other ProseMirror features are nice. We still need to do the work for incorporating them though, which is not the fault of ProseMirror, but because of all the existing work we have done.

For example, we have done the entire “concurrency model/collaborative editing (because those “events” can be treated as “deltas”, transmitted over the network and applied independently)” part and now if ProseMirror also has that, we’ll need to somehow reconcile the two.

This doesn’t really make a big differnet, thankfully. Given the huge size of this project, this part is insignificant, as long as it works well in the long term.

This is the real concern. With native ContentEditable people are already complaining about how long it gets (they have really huge documents), I can’t imagine how it would be like if everyline is a ProseMirror instance.

Have you worked with ProseMirror? Do you know if it’s possible to only activate one instance at a time, and leave others as non-editable elements until clicked? That might mean a ton of extra work… :cry:

OMG I’m have PTSD from work with this thread! (HTML/Markdown to WYSIWYG system is not a small task)

My personal use case is I like markdown in theory - it translates well between softwares and is simple enough for a luddite like me to write quickly - but hate the jumpey experience. So I’m all for this.

My two caveats are:

  1. I need to be able to export to markdown or copy text in markdown/html - like caret does for html and rich text (its a markdown editor)

  2. Please keep it accessible - I’m enjoying dynalist a lot because it is pretty good about keyboard accessibility. Solutions like the pop-over on highlight for editing controls are hellish.


SlateJS might be another option to consider as a contenteditable replacement. It’s quite flexible with a conceptually minimal design, and is supposedly designed with collaborative editing in mind. I’m only superficially familiar though.

What?! For those of us who can touch type Markdown is the best thing ever!!!

WYSIWYG only works if every formatting option has a keyboard short-cut. And those keyboard short-cuts follow a standard - except there is no standard!!! If I have to remember which short-cuts go with which app then I’m just going to be reaching for the mouse every time I need to format something. So either I won’t format as much or using Dynalist will become inefficient and cumbersome.

I’ve lost count how many times I’ve bookmarked a Gmail instead of deleting it because I Just came from Outlook (where Ctrl-D is delete, but in Chrome Ctrl-D is bookmark).

PLEASE keep Markdown!


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

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