marktext VS vrite

Marktext editor:

Marktext - A Markdown file editor. How to write in Markdown

Well, see comments below but you're wrong. I now huse Marktext and it's simply perfect.

I tried MarkText, but the collapsibility seemed terribly buggy, and a brief internet search did not increase hope.

I normally take Markdown notes with quick sketches from time to time with a Wacom tablet. I've used Xournal++ and Marktext to do all this, exporting my sketches into image files and inserting them into Marktext. However, I am starting to feel fatigued with this workflow and I discovered that Obsidian and the Excalidraw plugin could be an all-in-one solution for what I do, instead of having to work between two apps and exporting my sketches manually.

I have used syncthing + marktext[0] and or ghostwriter[1] depending on the content of my notes. For a daily journal I like to use ghostwriter as it has almost no distraction and it forces me to focus. It just got shifted over to being maintained by the KDE team and I really enjoy it.

I liked marktext over joplin for similar reasons. But I am probably a little overzealous in my search for distraction free note taking. I assume joplin provides more feature sets, I just happened to want less features for what I do on a day to day.

[0]https://github.com/marktext/marktext

I know I am a little late, but I have had great experience with MarkText (FOSS, a bit buggy, but the best at what it does by far), Ghostwriter (FOSS, a good editor, recently absorbed by KDE), Visual Studio Code/VSCodium with [Markdown Editor](andhttps://marketplace.visualstudio.com/items?itemName=zaaack.markdown-editor) (a WYSISWG markdown editing extention) and Obsidian (which I think you already have heard of).

Written using marktext

These reasons (and many others) are why I decided to create Vrite - an open-source developer content platform.

Vrite is an open-source developer content platform, featuring extensible editing experience, content management tools, and powerful APIs. It’s intended as an all-in-one, collaborative solution for product documentation, technical blogs, and knowledge bases.

So, I've been building Vrite as an open-source project for a while now, and I'm happy to finally share it here - with v0.2.0 now having official self-hosting support.

Let’s start by getting into Vrite. You can use the hosted version (free while Vrite is in Beta) or self-host Vrite from the source code (with better self-hosting support coming soon)

You can use Vrite via the hosted version (that’s free while in Beta) or self-host it from the open-source repo (though good support for self-hosting is still in the works).

Since Vrite (and Vrite Editor for that matter) is currently in Public Beta, new features and improvements are in active development. The best way to try it out right now is through the hosted version at app.vrite.io (free while in Beta) with better self-hosting support in the works.

The editor itself is a standalone app, extracted from the larger Vrite CMS project (https://github.com/vriteio/vrite) which you can also test out (only with sign-in) here: https://app.vrite.io/

The main output is JSON ProseMirror format. Other formats are processed from this JSON using Transformers and Vrite SDK: https://github.com/vriteio/vrite/tree/main/packages/sdk/java...

In the GFM transformer I try to follow GitHub Flavored Markdown spec, which technically doesn't support embeds. Since I didn't find any "common" syntax to use for the embeds, I just left them out. They're still there in JSON and HTML outputs.

That's one of the drawbacks of MD. That said, I plan to add an option like Markdoc, which has clearly defined spec for implementing custom blocks like embeds.

That said, for now, if you sign up for the full Vrite CMS, you can create a custom Transformer and process the output so that embeds are included in your desired format. That's what I'm doing for auto-publishing extensions for platforms like Dev.to and Hashnode. I don't know what your use-case is, but I thought it's worth noting.

The process basically came down to figuring out the position and size of the block node, given a selection of an entire top-level node or just its child node (source code):