Markdown Support

[KaratekHD]

I know this is a big one and chances of implementation are quite low, but I'd still like to post this.

Is your feature request related to a problem? Please describe.
I use RNote as my primary tool for pretty much all of my school work. I have all my subjects in the left toolbar and can easily access all of my notes. However, I also like typing notes in plain markdown files, as sometimes this is just the more efficient way of taking notes. To access these, I need to switch to a different application, which kind of breaks the neetness of having all my documents accessible from the sidebar and being able to switch between them using tabs.

Describe the solution you'd like
It would be amazing if Markdown files could be opened directly in RNote. Maybe the stylus toolbars could become options for switching between plain editing, preview and a side by side view in this mode?

Describe alternatives you've considered
Using another software, e.g. Apostrophe, for dealing with Markdown files. Not ideal, but gets the job done.

Additional context
I know this would probably require enormous code changes and there are other, more important things to deal with right now. Anyhow, it would make a huge improvement to my workflow and I could imagine it being useful for a lot of people, so I want to have it written down somewhere so that there is a chance of it getting implement in the far future. Thank you for your amazing work!

[LeSnake04]

I think one of the most important things is katex formulas.

loks like https://docs.rs/pulldown-cmark/latest/pulldown_cmark/index.html is a popular implemetation. Not sure if it has katex though.

Note: its used by https://lib.rs/crates/egui_commonmark as well

[k12ish]

I'm going to rescind my earlier comments, because this idea has clicked in my head in a way that's perhaps much different to what @KaratekHD envisioned: I'm thinking of implictly treating all text boxes in RNote as Markdown.

This simplifies the text entry interface completely: The buttons for Bold/Italic/Strikethrough text can removed, because this is all declared in the markdown. I'd still keep the font size options, and perhaps also the font family option.

Easiest Features: Rich text

Element	Markdown Syntax
Heading	# H1
Bold	**bold text**
Italic	*italicized text*
Blockquote	> blockquote
Ordered List	1. First item
Unordered List	- First item
Inline Code	(example omitted)
Horizontal Rule	---
Strikethrough	~~The world is flat.~~
Emoji	That is so funny! :joy:
Highlight	I need to highlight these ==very important words==.
Subscript	H~2~O
Superscript	X^2^

Math Mode

Element	Markdown Syntax
KaTeX / MathJax inline	$\int x \, dx = \frac 1 2 x^ 2 + C$
KaTeX / MathJax block	$$\int x \, dx = \frac 1 2 x^ 2 + C $$

'Interactive' Features

Element	Markdown Syntax
Link	[title](https://www.example.com)
Footnote	Here's a sentence [^1] with a footnote. [^1]: This is the footnote.
Heading ID	### My Great Heading {#custom-id}
Task List	- [x] Write the press release

Miscellaneous Harder Features

Element	Markdown Syntax
Image	
Table	(example omitted)
Fenced Code Block	(example omitted)

[LeSnake04]

The problem is, that existing texts might be using MD signs and retroactively formatting text fields will lead to issues.

So we need to either disable MD on all text fields created before MD support was added (by storing the new text fields with a special property) or make a toggle. I personally think a toggle is better.

I would say a picker like in the pen selector makes the most sense. This way the user can switch between plain text and MD, and we can even add more formats like latex in the future. Old text fields will just be plain text and can easily be made into MD fields

[Kneemund]

The main issue here is parsing and rendering Markdown, and the fact that what you see can't be what you get in terms of the layout (not even if you implement it like almost all WYSIWYG editors - e.g. "**Text**" is still considerably larger than "Text"). The latter is especially problematic when it comes to hyperlinks.

[k12ish]

retroactively activating formatting text fields will lead to issues

Ahh yes, this is something I should eleaborate on - Markdown escape sequences are well documented in the spec:

RNote could be backwards compatible with old files by markdown-escaping the text when upgrading the RNote file format.

From a UX perspective I think that "All text is markdown" is much more appealing than "Text is text, or maybe markdown, or maybe LaTeX". I do not see the value added by LaTeX compared to markdown with MathJax/KaTeX.

The main issue here is parsing and rendering Markdown

I think @Kneemund raises a very good point here, and this might be where most of the implementation difficulty lies. The typical way to solve this (Jupyter Notebooks, Obsidian ect.) is to display rendered markdown, but double clicking will allow the user to edit the underlying source code.

[LeSnake04]

The main issue here is parsing and rendering Markdown, and the fact that what you see can't be what you get in terms of the layout (not even if you implement it like almost all WYSIWYG editors - e.g. "Text" is still considerably larger than "Text"). The latter is especially problematic when it comes to hyperlinks.

I think the best way is to only show them only when editing the line like in obsidian and to ignore all formatting characters and links in () when calculating the bounds for auto-newlines .

[Kneemund]

That potentially overflows the viewport, or even worse, the whole canvas. And if you start editing a text box by clicking on it, the cursor would be either at the correct mouse position and incorrect text position, or vice versa.

[astro-ray]

I want to give my opinion about this as a user

I do not like the idea of markdown support in rnote. It doesn't solve any problem that exist in rnote, it doesn't make it any easier to use rnote than it already is.

I can already write equations using stylus, and I can even type. If #662 is implemented, things will look even better in Rnote. So, markdown support seems pointless.

Again, this is just an opinion

[LeSnake04]

I want to give my opinion about this as a user

I do not like the idea of markdown support in rnote. It doesn't solve any problem that exist in rnote, it doesn't make it any easier to use rnote than it already is.

I can already write equations using stylus, and I can even type. If #662 is implemented, things will look even better in Rnote. So, markdown support seems pointless.

Again, this is just an opinion

The main thing I would use it for it easy headings and formatting. Also, equations would be useful to quickly add something like $\alpha$ (\alpha) or $F_g$ (F_g) to an explanation, so I don't have to go back later to add them afterward.

But I understand that some don't need it so that's why I think It should be a per-field toggle in typewriter mode. (Once the user Disables it, it should stay disabled for future fields until they re-enable it, just like the other toggles)

PS: TIL you can use mathjax in GitHub comments

[LeSnake04]

That potentially overflows the viewport, or even worse, the whole canvas. And if you start editing a text box by clicking on it, the cursor would be either at the correct mouse position and incorrect text position, or vice versa.

A reliable but potentially ugly way would be that we take the size of the rendered or source of formatted parts, depending on what's bigger and apply it for both views.

That way things like links would have A LOT of padding.

Or we could redistribute the text as if it was plain text when editing the source. This would probably be the easiest to implement but make it impossible for the user to line things up while editing the text. Though it could be manageable if we only show the source for the currently selected element like in obsidian.

[albersonmiranda]

Hi there!

1. Excalidraw added support for equations via katex in 2022 (if I remember well). Their solution to back compatibility, which seems to be an issue here, was implementing a separate text box with math support (button 8 for regular legacy text box and on the right the new katex powered text box).

2. Following that idea, we could add a new text box (M|) for markdown powered textbox or at least katex support.

3. Which source file should I take a look at if I was to implement it? Never tried Rust but I'd like to give it a shot 'cause the lack of equations support is what's holding me for using rnote!

[damiponce]

Hi there!

1. Excalidraw added support for equations via katex in 2022 (if I remember well). Their solution to back compatibility, which seems to be an issue here, was implementing a separate text box with math support (button 8 for regular legacy text box and on the right the new katex powered text box).

2. Following that idea, we could add a new text box (M|) for markdown powered textbox or at least katex support.

3. Which source file should I take a look at if I was to implement it? Never tried Rust but I'd like to give it a shot 'cause the lack of equations support is what's holding me for using rnote!

Hello! I am also interested in trying to implement a crude version of this (mainly for personal use).

Rnote has been the best handwriting/note-taking software I've stumbled upon, but LaTeX equations would still be a must for me to daily drive it.

Will try to dive into it if I have the time, but if anyone else also begins this feature, hmu!

[Atreyu-94]

For math you may be interested in implementing Typst, it is very easy to use and the executable is very small and also programmed in Rust :) https://typst.app/