this is the topic in regard to the above-mentioned topic.
Anything on how to do this, how it shall be done, what features in shell include etc. is discussed here if an existing topic hasn’t been created yet, see idea description below.
Your interest in this idea shall be announced here, otherwise, it gets easily lost as we would need to remember each introduction.
This topic is used to update the specification of the idea as well, even if there is an existing topic, so interested students, watch it!
Anything that shell be discussed privately as e.g. if it involves your proposal will be discussed through a private channel what is currently in discussion.
The current editor shows the Markdown text on the left side and the rendered HTML on the right side (a split view). We would like to add another editor option, which would be a WYSIWYG editor, where the user can directly edit formatted text. This would not replace the split view but rather be an alternative editor and the user can choose either split view or WYSIWYG.
Expected Outcome: To add a WYSIWYG editor to the desktop app.
may you analyse it first
There might better options as Laurent takes care of the entire app, he may have not time to check out each alternative in details.
We can start listing/talk with the community, which editors could be implemented.
Then is up to you, which suits you best.
@PackElend are all GSoC projects for singular students or can group efforts be submitted? I didn’t see much of anything about that in the FAQ but could have overlooked it
For WYSIWYG, I’ve started the branch also as a way to refactor the existing text editing logic, which had a few hard to fix bugs due to spaghetti async code, and also as a way to make it more modular so that the editor can be switched more easily.
I’m not sure if it still makes sense as a project idea. Maybe as PackElend said, what could be a project is to try and evaluate various text editor components and see which one would work best for Joplin. You would start from my PR and swap the TinyMCE component with for example Draft.js or whatever editor you want to try.
In this case, a completed project won’t necessarily mean a production-ready pull request, but just a proof of concept (or several) that shows what can be done and answers a few questions - how the editor can be integrated? is it better in terms of performance? does it lead to cleaner code? can its API be extended for our needs? etc.
yep that is the case, at least that is the way other orgs did it in previous GSoC seasons. The challenge is define the sub-projects properly so that each can be evaluated correctly
This is the only big thing that is missing for me (I switched from OneNote some weeks ago and I still migrating all my notes to Joplin). Really great idea !
PS : could be cool that a simple line break in the editor makes a line break in the viewer. For now, we have to add two spaces after a line to do this. Maybe with WYSIWYG editor this will not be a « problem » anymore.
This behavior is actually part of the markdown spec, so likely it won't be going away. That said, is it possible that you have the soft breaks plugin enabled by mistake? I've never had any issues with line breaks in Joplin.
Example of behavior that I see
some text
This text will be on another line
some text
This text will be in another paragraph (there is additional spacing in the viewer)
Example with soft break plugin enabled
some text
This text will be on the same line as some text
If you're experiencing the behavior of the last example, it means that you've accidentally enabled the soft breaks behavior.
I’m really interested in this project and I think this can be well achieved with slate
The complete editor will have these two features:
A WYSIWYG Slate-based editor that edits rich text and calls an onChange callback with the modified Slate DOM.
A TextArea-based markdown editor that edits markdown text and calls an onChange callback with the modified markdown text. (which I think is the feature that’s already implemented or something similar)
then using a ‘markdown-transform’ package to transform Slate DOM to/from markdown text.
we could allow people to either edit rich formatted text using markdown and provide a Html preview( this is the feature that already exits), or allow them to edit using a WYSIWYG editor and use markdown for persistence, then down to HTML.(the new feature).
Got the Idea from how Accord handles theirs
I know there's been endless discussions about what a MD WYSIWYG editor should be in another thread that's now closed (so, fair enough, discussions actually came to an end...), but as such editor is now under active development, let's add one more highly valuable (or not...) opinion: mine
WYSIWYG editor is something I was eagerly waiting for in Joplin, for the sake of no longer having to rely on an external editor (usually Typora) when I wanted to work in WYSIWYG mode (not always the case, but for longer and more formatted notes it is useful)
I just tried the experimental WYSIWYG Joplin editor and was disappointed to see it was a "fully" WYSIWYG one, i.e. it doesn't really matter if the underlying format is MD or something else.
What I like about MD is that you format as you type, and in a very quick way : can't go much faster than typing '#' for formatting a line as a title header.
What I like about WYSIWYG editors is that you see what it's gonna look like where and while you type : you see it all the time and without needing to waste screen space by showing twice the same text
What I therefore like about Typora's approach is that it's the best of both worlds : in other words, I don't always need/want to use WYSIWYG, but when I do I think it's a great benefit to be able to keep being able to use markdown syntax when I type, so I'd love Joplin's WYSIWYG editor to be able to work like this.
Another interesting (and simpler to implement?) approach may be something more like what Zettlr does for instance, and that was mentioned a little in this other thread : a mode where formatting is applied and markdown code is still visible (in light grey for instance). So this is somewhat half way between plain text MD editing and WYSIWYG : it's a WYSIWYG editor that doesn't hide formatting code... or it's a text editor where syntax highlighting is replaced with actual formatting. Question is how more complex items like tables or equations are shown in this mode (I'd vote for the Typora / Zettlr way, i.e. rendered at least while not editing it)
+1 for mimicking Typora. It's what I'm using currently.
I think a simple step forward would be to render just the selected line back into markdown, while the rest of the doc is visible as WYSIWYG.
One of the main issues right now is that the WYSIWYG editor does not perform well with large documents. I have a 100+ page journal that basically causes Joplin to stall if I make any edits in the WYSIWYG editor.
Actually, even editing the code directly, there is a 1-2 second delay after any edit, but with WYSIWYG, this becomes an unbearable 4-5 seconds.
