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
- So, it you want to switch MD to WYSIWYG â no problem. Same keyboard shortcuts, same result
- 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
2 Likes
the pro-markdown camp 
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 
.
2 Likes
@Erica Two years later 
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 Notejoy.com 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: Markdown syntax â Notejoy
Being able to start a line with space and 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
Hello,
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!
2 Likes
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.
2 Likes
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.
Thanks!
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.
3 Likes
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.
3 Likes
today is 2020-02-01, will this feature release soon?
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.
3 Likes
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.
9 Likes
To add to Shidaâs reply, here are some things weâve been up to in parallel with WYSIWYG: https://blog.dynalist.io/2020-january-update/
3 Likes
â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.
3 Likes