Mark Text: Simple and Elegant Markdown Editor Focused on Speed and Usability | Hacker News Reader

Mark Text: Simple and Elegant Markdown Editor Focused on Speed and Usability

marktext.app

206 pointsseverine141 comments

The important feature worth mentioning (more than “simple and elegant” and “focused on speed and usability”) is that it directly renders the Markdown (in the editor itself, not in a separate pane or window), giving a WYSIWYG feel while still being backed by a plain-text (markdown) format that if needed can be edited directly (even in an different editor). This I've found to help enormously with being distraction-free (while still having the peace of mind from not creating an irrecoverable binary blob). Of course, to someone else it may not be a big deal.

Before seeing this just now, Typora (https://news.ycombinator.com/item?id=21458977) was the only Markdown editor I had encountered that does this, but it is not open-source. Another was the halfway-in-between (shows both syntax and rendering) Abricotine (https://github.com/brrd/Abricotine) which has the sense to mention it as the main feature: “Markdown editor with inline preview” and “you can preview your document directly in the text editor rather than in a side pane”.

Are there any other editors like this?

Yeah totally agree I found typora very standing out between all markdown editors because of that feature.

> The important feature worth mentioning is that it directly renders the Markdown, giving a WYSIWYG feel while still being backed by a plain-text (markdown)

Exactly. It has a little bit of an IA Writer feel except that you no longer need a preview window thanks to this feature.

Dropbox Paper works similarly.

https://bear.app/ does it pretty well.

They use a proprietary library and don't allow local folders of text files, though...

Bear and Ulysses, while nice, do not do what OP is talking about (unless they just did an update I’m not aware of).

Both of these apps do not abstract away the markup after a word is typed. This is the killer feature of Typora, along with the ability to completely redesign the entire editor yourself with a custom style sheet (along with awesome image management).

Typora has completely taken over my markdown workflow because of this.

I’ve tried Bear, Ulysses, IA writer, and countless others. None have this clever blended preview like Typora.

Bear does it (just less elegantly)

I've used Typora and enjoyed it, but I've learned that I really dislike this abstracting away of the Markdown. I'm glad it exists though — and it's a really excellent product for those who enjoy this feature.

My understanding is they store everything in SQLite. Their business strategy is to charge for sync (although manual export is free)

Given that it is branded as a note taking application it makes sense both from a business and implementation point of view.

Bear also kinda uses its own rendering for some things. Like dashes turn into checkboxes rather than unordered lists. Again, for a note app, checkboxes are really neat!

I’ve been using it for 2-3 month and really like it!

There is a vim plugin [1] that automatically renders markdown in your browser with synchronised scrolling. It felt like magic when I first used it.

[1] https://github.com/iamcco/markdown-preview.nvim

That is cool no doubt, but to be clear I was referring to rendering markdown in the editor itself, as you're typing. (Not in a separate pane or browser, which almost every Markdown editor does.) For example, if you type asterisk-foo-asterisk-space you should (in the editor) see an italicized foo followed by a space, and if you move your cursor to the “foo” you should be able to see the asterisks and edit the syntax again.

Xcode does inline rendering also.

What I’d really love is a way to get the GitHub flavored markdown rendering engine in an offline local editor. Any that do this?

https://ulysses.app/ does this well. Also not open-source, but still, a very well made app

After trying the Mark Text demo (very nice), I got very curious about the editor control and how I could integrate it into something I am thinking about working on.

It looks like the editor is called Muya: https://github.com/marktext/muya

And according to this issue: https://github.com/marktext/muya/issues/6

The best way to get access to the latest version of the control is to use the source here: https://github.com/marktext/marktext/tree/develop/src/muya

I find these two quite nice: * http://wereturtle.github.io/ghostwriter/ * https://uberwriter.github.io/uberwriter/

I've made a web-based one called Elltwo where you can toggle between plain text and rendered markdown on a line-by-line basis. I've found it to be a good midpoint between full on WYSIWYG and just editing raw text. It also supports equations, references, footnotes, etc.

Demo here: http://dohan.io

How is the text/data stored per cell? I tried building something similar to this based off cells in Jupyter notebooks, but one issue I encountered was with having a one-way binding from editor to render.

One problem with this is with to-do lists, where instead of having the user modifying the underlying text representation in the editor, I wanted the user to be able to check off an item via the rendered html. For this, it seems like I needed three components: an editor, a render, and a non-flat data model.

The cell data is always stored as plain text, on the client side simply with an attribute. And you can only ever edit cells as text, so those issues never come up. I could see how the checkbox would be tough though because you'd have to decide which line they clicked on in the text representation.

I've thought about porting to Jupyter too, but the plugin system on JupyterLab is pretty involved, and you lose plain text storage on the server side.

Ya Typora was my first thought as well. It does almost everything I need except generate the table of contents (TOC) for things like GitHub. I've used markdown-toc and similar CLI tools, but it would be great if they were built in. A few others for ideas:

https://stackoverflow.com/questions/11948245/markdown-to-cre...

Emacs org mode can also do this, it's really enjoyable to not see some of the semantic entries, but having them still exist in the background.

It's not an editor, but ProseMirror is something that I'd recommend checking out if you wanted to build a web-based WYSIWYG markdown editor with possibly extended features. There's also Notion.so. Both of these aren't explicitly markdown, but if you keep the representation simple and flat you can always export it as such. I came across both of these editors when I saw a friend with a Chrome extension (Papier) which replaced new tabs with a markdown-esque page, but it didn't support inline math. Marktext, as mentioned in other comments, is open-source but I found it hard to just take the editor Muya and attach that onto a webpage.

http://www.inkcode.net/qute does it quite similar (on a paragraph basis instead on a word basis) and it's open-source

MarkText is opensource too.

Quip works quite well and is collaborative + multi-editor

https://www.zettlr.com/ (https://github.com/Zettlr/Zettlr) is what I used before I discovered MarkText. Also open-source, also WYSIWYG, also Electron I believe.

One thing I really wish some of these editors had were an IDE-like sidebar.

Whenever I'm editing markdown files, it's usually in a folder of notes, or blog posts, or writing of some kind. And it'd be nice to be able to cycle through several open files like you would in VS Code.

I tried writing my own but -- I just didn't have time and got bored of it.

Have you heard of editors that are specific for markdown and have this feature?

Code supports markdown files natively:

https://code.visualstudio.com/docs/languages/markdown

I use this extension which I like a lot:

https://marketplace.visualstudio.com/items?itemName=yzhang.m...

You should check out Mark Text (which is the main topic of this thread) - Mark Text can open folders and it looks very similar to VSCode. In the settings you can even say "open this folder by default, if I open Mark Text"... this looks like it would make quiet a nice and easy note taking solution.

> Whenever I'm editing markdown files, it's usually in a folder of notes, or blog posts, or writing of some kind. And it'd be nice to be able to cycle through several open files like you would in VS Code.

You pretty much describe how I'm using MarkText all the time. On the left, you have a file panel (or search or navigation inside your file) which you can hide/ show with a keystroke. On the top, you have several tabs for your open files. And yes, you can set a default folder.

I decided to give it a try, and it's almost a 100MB to download. Due to being unsigned, Mac OSX blocked running this web app. Why isn't there a demo online that I can try in my web browser? Isn't this supposed to be a simple electron app?

Anyways, I went to the trouble of unblocking it. This involved going to OSX's settings dialog and finding the Security & Privacy window to unblock.

The text rendering is awful. It's blurry and smudged on my non-retina display due to not using subpixel smoothing. Here's a screenshot comparing Atom (top) to Mark Text (bottom): https://imgur.com/UEJbsl4

Highlighting and pasting text is totally unpredictable. Try pasting in 10 * characters and you'll see that it's almost impossible. How are you supposed to do this? Sometimes it replaces * with \*, sometimes not. And sometimes it replaces it with - ??

I tried to copy paste a few paragraphs of text a few times, and once it turned into this strange highlighted text that when I started a new paragraph, deleted all of my newlines. What's going on?

This editor does not seem ready yet.

> I went to the trouble of unblocking it. This involved going to OSX's settings dialog and finding the Security & Privacy window to unblock.

The "right" way to do this is right-click on the application, and choose "Open". This allows a one-time bypass on a per-application basis.

Interesting. I didn't know that using "Open" was any different than double clicking. Thanks for the tip.

I think the theory is that when the user right-click and select “open”, this is more of a conscious choice. Because of this extra effort, you get the option to go around the default security.

I find this to be a good trade off between running any unsigned binary and complete lockdown. It’s enough of a barrier to make you stop and think, but doesn’t take too much effort to get past.

Perhaps this has been fixed; running macOS 10.15.1, I didn’t have to do anything special to run it—just double clicked.

If you're unhappy about your OS preventing you from running applications that you want to run, you might want to consider switching to another OS.

This is the first time it has happened to me.

Similarly if you’re unhappy that a developer hasn’t signed their releases so you can be sure it hasn’t been tampered with, you might want to consider switching to another app.

Actually his OS is saving him from boated and useless "apps"

> Try pasting in 10 * characters and you'll see that it's almost impossible.

Works fine for me: https://i.imgur.com/QssB5YV.gif

Note that:

• The premise of the app is that you type or paste in Markdown syntax, and see the corresponding rendered output in the editor (except when the cursor is inside that area). As asterisks have a special meaning in Markdown, you should expect to see bold text (rather than the asterisks) when you type or paste something like asterisk-asterisk-foo-asterisk-asterisk.

• The intended meaning of ten asterisks in a row is hard to predict from the Markdown syntax definition. Their rendering as two bold asterisks seems to be not what the majority of Markdown converters do, but according to Babelmark it is consistent with a few, including the original Markdown.pl: https://johnmacfarlane.net/babelmark2/?text=Asterisks+on+the... (Of course, it is best to avoid any such edge cases where Markdown converters differ; CommonMark notwithstanding.)

> Anyways, I went to the trouble of unblocking

Phrasing isn't flattering to an open source app given away for free, with no tracking.

However, you are right on the usability. It's worthwhile to file a bug to sign the app, and if possible, fund the certificate

I would prefer if I didn't have to do that. Somehow other apps don't, and this was the first time I had to unblock something.

I'm sure once the project have enough regular sponsors to pay the annual $100 fee for notarization by Apple they will gladly do it. Until then enjoy foss and support if you want/can.

For instance https://qgis.org just started notarizing for MacOS Catalina, but it's easier with the huge userbase & sponsors.

Can anything running on Electron be classified as simple? Just saying. (yes, I am that guy in this case)

I like the idea behind it though.

I think that this argument is, frankly, over. Electron is the way to build cross-platform apps that don't merit separate UI code for each platform.

Electron wins because Electron apps are able to deliver consistently decent UX, something that never happened with Swing or GTK+ or WxWidgets or whatever.

Sure, it eats RAM. It turns out that I care about that so much less than I thought I would. I'm rarely using 100% of my system's RAM these days, so I'm willing to burn a couple hundred MB on widgets continuing to be sensibly drawn and laid out when I resize the window.

I think you're thinking of a different argument. I never said it doesn't provide consistent UX.

It's just that when I hear a "simple markdown editor", I don't envision an app with a bundled web browser. I'm sure it looks great and all that.

When they say "simple markdown editor", they're pretty obviously not talking about implementation details. They're talking about it being easy to use.

As far as the argument goes, I'm not sure they're really separable. If you have an Electron app that markets itself as being simple (as in "easy to use"), and someone says, "No it isn't, because the stack it's built on is complex", their unstated major premise is that implementation details are more important than UI. Leaving it unstated doesn't mean it shouldn't be addressed head-on. One of a syllogism's legs can easily be both tacit and the crux of the argument at the same time.

Text editors don’t need all the widgets and controls. They basically need a context menu (and Electron’s menus are horrible as they provide none of the native OS accelerators and integrations), a open/save dialog (pretty please don’t use a custom UI here!), and maybe a menu/toolbar. The editor itself is custom code (whether html/css/js or native), and that’s where the performance benefits of native code shine best anyway.

> and that’s where the performance benefits of native code shine best anyway

That's right, now you just have to deal with open source OpenGL libraries or of course write it yourself.

Handle unicode, sub/superscripts, RTL text, typography nuances, LaTeX etc. by yourself.

(See more at https://gankra.github.io/blah/text-hates-you/)

Also do it in your free time because probably you won't make a living out of it.

So I totally understand why anyone would pick a browser engine where all of this is super easy to solve.

Of course, there's no middle ground between "using a whole browser engine" and "coding your UI in raw OpenGL".

Have you heard of, say, Qt?

>Sure, it eats RAM. It turns out that I care about that so much less than I thought I would.

It sure is nice having a powerful developer machine with 16 or 32 gb of RAM. Just remember there are a lot of people out there running on 4gb laptops or even less. These days, the OS, web browser, and Slack alone are already enough to max it out and start swapping.

If you want to keep your RAM usage light, go ahead and use vim. Other people choosing to use different apps is consuming their computer's memory, not yours.

I'm also not sure you can just assume that an Electron app will be a giant memory hog compared to the alternatives. I just decided to go and give it a quick look-see. Right now I've got both vscode and IntelliJ IDEA open at the same time. (For my purposes, they're at feature parity, except that I don't like vscode's Java plugin). IntelliJ, a non-Electron cross-platform app, is consuming 3 GB of RAM. vscode, an Electron app, is using 50MB. That's 1/60 as much. Meld, a GTK+ app that doesn't do nearly as much, consumes 100MB just sitting idle, which is twice as much as the Electron app does.

I'll come out and say it: I suspect that, deep down, this argument is not really about memory or anything like that. It's really a proxy war about JavaScript. Which, I get it, I hate JavaScript too. I resolutely avoid working on things with UIs at work, probably to the detriment of my career, just to avoid programming in JavaScript. But I've also got to concede that Electron has accomplished something that everyone else has consistently failed at: Delivering decent cross-platform GUI applications. And it's pointless to complain about people using X technology when it has no truly viable alternatives.

> Delivering decent cross-platform GUI applications.

Qt, Gtk+, WxWidgets... There are lots of ways to skin this cat.

An 8 gig stick of ram costs about thirty dollars. It doesn't make sense to run 4 these days.

Not everyone can or will upgrade their computer’s RAM.

Older Intel chipsets don't support more than 4 Gb. New chipsets and motherboards also have a limitation, typically about 16 or 32 Gb. Doesn't it look artificial? What is the reason for it? Of course, to make sure that the consumer won't be able to use them for too long without paying for a new one.

Most current entry level AMD and Intel motherboards support 32 or 64 GB RAM (in fact, I couldn't find one that supported less). These are rarely over $100. Boards supporting 128GB of RAM start around $120-150.

Seems reasonable for 2019.

What about the people using prebuilt machines, or ones with 4GB of soldered-in RAM?

Thats not really what I was responding to - they were saying current chipsets and motherboards are artificially limited to 16/32GB, which isnt true. Of course there are are specific systems like laptops that are limited to less than that.

Should not "entry-level" motherboard cost around $20-40 and not $100? Not reasonable at all.

Also, in laptops you cannot upgrade the motherboard.

> Should not "entry-level" motherboard cost around $20-40 and not $100? Not reasonable at all.

No? ~$100 is remarkably cheap for a new motherboard, especially if you are complaining about needing 32+GB of RAM, which costs substantially more than $40. If you want something like a $35 Raspberry pi, buy one and accept its limitations.

> An 8 gig stick of ram costs about thirty dollars. It doesn't make sense to run 4 these days.

It does not make sense if 4 Gb mean that you can only run a browser and Notepad.

If, however, you are a bit older and you remember the time that you had the choice between 4 MB and 8 MB and people were still able to do all their computer stuff, including internet, in a graphical environment, then you thoughts are more in the line of: what the fuck are these lazy and incompetent programmers doing these days? And this is coming from someone who earns a living as a developer.

There were a lot of hours spent and features unimplemented those days in want of RAM. Now we don't have to do that- we can do more, and we can do stuff way faster as developers.

If you spend a half hour over the entire life of your machine even considering RAM, you might as well double it for $30.

Using RAM is good. It's fast, it's cheap, and anybody with 8 gigs has it in abundance

May I ask what unimplemented features you're referring to? I think one of the biggest issues the older crowd has with Electron apps is not only that they eat up 500MBs of RAM, but also that they only have a tiny subset of the features contained in apps that ran fine with 500KBs.

"Hello World" in Electron is 100MB. That's the bare minimum. It's quite insane.

Many (most?) consumer level machines have soldered RAM these days. They may or may not have an available expansion slot.

I haven't seen anyone use a desktop for development in years...

The Windows tablet/notebook (hybrid) being sold as their latest product by a company I'm doing business with at the moment has 4GB. It's a shame, because Electron would totally fit what their business runs on those tablets, which is a Javascript-based graphical environment...

Then write an alternative using different technologies. Those writing electron apps now are not obliged to do this for you.

Not everyone has a system with over 8 or 16 gigabytes of RAM to run such apps.

So, let's talk with real numbers here.

I happen to have a Markdown file open in MacDown, a native application, right now. According to Activity Monitor, it's using 67.1 MB of RAM. I also downloaded Mark Text to take a look at it. So now I've got the same Markdown file open in that app, too. It's using 73.9 MB of RAM.

I will admit, that difference in memory consumption is equivalent to seven instances of vim, and I'll keep that in mind the next time I'm trying to get things done on a Raspberry Pi Zero. (As one does.)

But, on this 6-year-old computer, which does not have "over 8 or 16 GB of RAM", I'm still not sweating that 6.8 megabytes.

That is difficult to believe. I unpacked Linux version of the app, Electron binary is 120 Mb, resources.pak is 8 Mb, ICU library is 10 Mb. How can a whole Electron app take just 74 Mb? The numbers don't add up.

To test it myself, I started the program (with --no-sandbox because it requires root privileges otherwise) and measured memory usage using smem:

    $ sudo smem --userfilter=nobody -k --totals

    PID User     Command                         Swap      USS      PSS      RSS 
    23365 nobody   /tmp/.mount_markteqQvqZF/ma        0     6.3M    14.2M    37.7M 
    23388 nobody   /tmp/.mount_markteqQvqZF/ma        0    46.6M    59.4M    90.9M 
    23363 nobody   ./marktext --no-sandbox            0    53.3M    76.3M   118.4M 
    23392 nobody   /tmp/.mount_markteqQvqZF/ma        0   121.1M   142.3M   183.0M

PSS (Potential Set Size) [1] numbers are additive unlike RSS, so we can sum them and get around 291 Mb of RAM. This counts pages, that are shared between several processes, only once.

Either MacOS uses RAM several times more effective than Linux, or Activity Monitor is showing incorrect numbers to make impression that Mac apps take less memory than apps on competing operating systems.

[1] https://en.wikipedia.org/wiki/Proportional_set_size

"Electron apps"

Wrapped web engine and the site does not an app make.

I doubt you even need a desktop app for simple markdown editor. Just a browser tab is good enough https://markdown.site

Can any car described as comfortable and family friendly which run on gas?

I mean, in the long run, fossil fuel usage is going to make your family pretty miserable, so probably not.

Sure. You're just not allowed to claim it's lightweight.

Can we focus on the actual product. I feel like this discussion comes up every time and it's not interesting.

And yes, Electron isn't simple. No one cares. The product itself is simple to use (presumably). When they said simple, they were not referring to implementation details.

I’m currently using Vnote https://github.com/tamlok/vnote/ after trying Typora and other Markdown editors. What I like about Vnote is it is based on Qt and has most of the functions from Typora plus Vim mode, a lot of keyboard shortcuts, good search capacity across different notebooks (which basically folders and sub folders containing markdown files), and some extensions like MathJax, Flowchart, Mermaid. Vnote (and Typora) supports defining folders for images or attachments (relative or absolute path). Even though it does not have a kind of webcliper extension for browser like Joplin, you can copy the content of a webpage and paste it directly into Vnote (also Typora), it can reformat the content as markdown and copy the associated images to the defined folder. I used Joplin before and still like it a lot but recently switched to Vnote and version-control the notes with git. For that, I can "sync" the content of my notebooks using git across different devices (for iOS, I use Working Copy as a git client and it can render the markdown notes with images). Vnote needs to store the structure of your notebook and other metadata such as tags in JSON files. You do need to have those JSON files otherwise Vnote will not display the tree of your notebooks. But basically you can use other editors to open Vnote notebooks because they are just folders and markdown files.

This looks promising! Downloading now. Thanks for pointing it out!

I am very happy to see the discussion about Mark Text on Hacker News. I am the author and main maintainer of Mark Text. I will seriously think about the suggestions for Mark Text which you comment here. I also welcome everyone to submit the issue and suggestion to Mark Text on GitHub https://github.com/marktext/marktext. Thank you everyone.

I appreciate Mark Text a lot, have been switching from Typora at the beginning of the year. I'm taking all my notes with it and find features like KaTeX and Mermaid very useful. Some remarks and questions from my side:

- How is the current status the Plugin system? It would be cool to try integrating features like Pandoc Citer from VSCode or LaTeX autocompletion, but I guess that would be too much for the core.

- Since you're already using pandoc, more available export formats or the option to define own exports via settings would be useful!

- Images are linked to their current path when added. I liked Typora's feature of automatically copying them into an asset folder a lot.

Overall, great work! I might learn Vue an Electron just for the sake of MarkText. Don't listen to the Electron critics - having a reusable rendering engine and the same features as in GitLab available locally is way better than saving some RAM.

I'm really interested by the sponsorship bits at the bottom; they're using both Open Collective and Patreon. It seems to me that one of the problems with going beyond the scratch-a-personal-itch level is how unsustainable it can be. I'd love to see that normalized, so that people who create a lot of value for others aren't economically penalized for choosing open source.

This website is completely unusable on mobile. It’s worse than a pre-smartphone site because it disabled zoom out so the content is just cut off.

I get that Electron is accepted as a way to do multi-OS apps. However, whenever possible, I find there are better OS specific apps. As I use Linux and Mac, I find the best app for each.

For example, on my work mac I use Ulysses, and sync to a cloud folder. Then on Linux, I use caret or typora with the same synced folder. Caret/typora aren't as nice as Ulysses (IMO), but as they all support markdown, all three are fully compatible. I'd rather not use an inferior app only because it's cross platform. Since the content is transferable between apps, and is synced outside the app, this seems like a pretty good compromise.

If I could buy a high quality markdown editor on Linux that rivaled Ulysses I would.

Isn’t Typora electron too? Or is their Linux version a native app?

Yes

It is. But I spend more time at work using a Mac. I would rather use the best app for the OS. On Linux, there isn't anything as good as Ulysses.

This website look pretty broken in my mobile browser.

Came here to say the same thing. Sorry to be “that guy” but it’s really hard for me to have any positive thoughts of a front-end web project when it’s website doesn’t work on mobile.

Came here to say the same, glad I'm not the only one.

The website is unusable on mobile so I can't even check out if the app is any good. I guess I know enough already.

FWIW I looked the github page instead which renders nicely

https://github.com/marktext/marktext

Thanks, turns out it looks pretty cool and I'll actually try it, from the experience with the website I was ready to forget about it and move on.

You couldn't just tick the "Request desktop site" box available in every browser? But yeah I guess you know enough already, the dev should apologize because the website of their free product is not mobile friendly.

I'm also a developer, and if you're not mobile-first let alone mobile friendly, you're doing it wrong in 2019. Why do I want to pan and scroll around a tiny site rendered in desktop mode on my mobile for your brand new product?

It's either lazy or ignorant and neither gives me confidence in their software.

It's a free product.

Doesn’t make any difference, it looks the same.

Were you planning to run this markdown editor on your phone?

Not op, but there are markdown editors for phones now.

And the website? Can’t even tell which OS the app is selling for.

Windows, Mac, and Linux.

https://github.com/marktext/marktext

Not sure how you missed it, but it's extremely clear: https://i.imgur.com/0WL8XNE.png

Not affiliated with this product, just surprised at how this could possibly be unclear.

Not so clear on a mobile device: https://i.imgur.com/LD5yMab.jpg

Not affiliated with the OP, just surprised how a sub-thread about a broken mobile experience could possibly be unclear. ;)

This comment makes no sense.

I don't plan to fly to Japan on my phone but I still want flight booking sites to work on it.

Reading about an activity and doing the activity are two different things yeah?

I don't know the motive for the site design, but I wonder if perhaps it wasn't coded for mobile because the app is not compatible with mobile devices but rather only Windows, Mac, and Linux.

https://github.com/marktext/marktext

Even if you’re making a CLI application the website still needs to work on mobile. Responsive design is the only web interface design that is relevant.

I'm surprised by how much I like this idea. (I have not tried it yet.)

Right now, I use vim for almost all of my text editing. I pop into JetBrains IDEs when their analysis tools or debugger integration are helpful to me. And I use VSCode for most markdown editing. This, if it's good, could replace VSCode for me with a tool that's much better for the purpose I need. So there's basically no new trade-off for me... I've already caved on the electron front for markdown editing anyway. This could just make the payoff for that trade much higher.

I tend to use VSCode for markdown as it gives a preview, though I also use Vim for it as well. I pretty much exclusively write any kind of documentation in Markdown these days. Including my own notes.

I tried this Markdown editor. But very quickly decided I didn't like it, I felt handicapped not seeing the markdown and losing Vim bindings. But partly it's because I don't actually really need the visualization of markdown. I'm happy looking at the raw syntax of highlighted markdown. In Vscode I'll open the preview just to check I haven't done something silly. Also, the rendering of markdown in VsCode seems nicer ( perhaps more familiar )

> I pretty much exclusively write any kind of documentation in Markdown these days. Including my own notes.

Same here. And the preview, particularly of inline images, is what I like about VSCode for it.

The main thing I like about this editor after trying it out for a little while today is the table stuff. For some reason that doesn't work as well for me in raw syntax as the rest.

I think my ideal markdown editor would basically be the VSCode plugin's auto-suggestion of bullet syntax, the ability to paste images inline and have them land in a specified directory with a predictable path, and a good table editor.

This one does a good job with the tables IMO. I haven't tried it much with images because that didn't really come up today.

12.3K stars on Github; over 1.300 commits; 197K downloads. 0 supporters on Patreon

That's the sad reality for open source devs.

They do have 15 open collective sponsors.

The tiers are $50/$100/$500 a month with a goal of $5000 per month to spend half of his free time on development.

For a markdown editor? I see most Patreons with tiers around $3/$5/$20, and those are actually complex/ambitious.

Yeah, those are definitely some weird tiers.

The beauty of these services is that I can toss a couple bucks a month to projects that I use. I don't want my name in credits, I don't want a dinner with the author, I don't want sneak preview access to whatever. I just want an easy way to support something that brings me value.

Not even my total monthly contributions hit $50.

I keep a pseudo-bullet journal in markdown. Unfortunately, I rely on two things this (and a lot of other) Markdown editors won't do:

First, "-", "+" and "*" are all legal bullet characters for creating unordered lists.

This allows you to put further semantic meaning into your plaintext (for me that's notes, new tasks, events respectively) though it does get lost in render. This editor loses that distinction.

Second, and this one drives me nuts with MD editors not supporting it, "+<TAB>text" is just as legal as "+<SPACE>text" for Markdown--the spec, such that it exists, is just whitespace after the bullet.

I personally use that to create a bujo-style gutter column between the <UL> bullets and the text where I can insert a space and a resolution symbol without disturbing plaintext alignment.

So, "+<TAB>New Task" eventually becomes "+<SPACE>^<TAB>New Task" to indicate it's been tracked, for a final render of "o ^ New Task"

nvAlt is one of the few that does this right, and will actually copy the "+<TAB>" to the next line as a leader instead of only copying "+<SPACE>" or not treating the "+" as a bullet at all if a tab follows.

This editor won't even let you input a tab character. Tab always indents, whether it's opt-Tab, ctrl-Tab, or what.

I think Markdown is great, but the value I've seen is more in the semi-formatted plaintext representation than just being a text-based way to WYSIWYG. If I want WYSIWYG there are significantly more direct ways to get that. I wish more of the MD editors concentrated on optimizing the plaintext experience, as nvAlt is getting a bit long in the tooth.

The inline MathJax editor with live-preview is nice, as is proper markdown parsing (you can put code-blocks inside lists! gives side-eye to Bear.app). And it's got a pleasing stylesheet. But I don't really see what this brings to the table to be honest.

It's electron so it doesn't feel native, and it takes over a second to open a nearly-empty document. OS-level key-bindings (Ctrl+A/E etc on Mac) are overridden or broken in weird ways, and some usual typing conventions don't work (double-enter to break out of a code-block). You can't click to move the cursor in a number of situations. The "type @ to insert something" seems weird - markdown by its nature is easy to type. The editor kinda supports tabs but I couldn't figure out how to switch them without the mouse.

All this said, my biggest gripe is that I can't change the font to a monospace font. Yes I'm writing prose, but I want to write in a monospace font. Always. I understand this is a personal preference, and the author lets you change the font but only to a small handful of pre-determined fonts - there is no option to use a custom font. That is just..weird.

This thing shows some promise if it can be made faster and made to support a more ergonomic writing environment. As it is it's just kinda a neat demo with some cool features but an overall unfinished UX.

What I need from a markdown editor is the preview and vim keybindings that's why my editor of choice is vscode + vim keybindings + markdown all in one extension. Beside this combo all you can have is either vim keybindings without preview or preview without vim keybindings so if somehow marktext (which is great because open source) can have both it will be my editor of choice without any doubt.

When I say "preview" I also include WYSIWYG style.

Came here to say this, particularly RE: vim key binds. If those were added, I'd be much more interested. Even without the binds, though, I think it feels pretty good to use.

This looks really nice...

... except like every other apps around there it only supports Markdown

Feature request:

Please add an option to convert the resulting file to a better format like Asciidoc and other better markup formats

Maybe using pandoc.

WHY?

I feel unwell with Markdown

Markdown deserve credits for having found a real important problem to solve

on the other hand, it's not a good solution to that problem

... but just good enough that its bad aspects are not obvious

Combined with its current popularity, this makes progress very hard

But there are so much things that are wrong with Markdown.

Nested lists? I get them wrong every time.

Images syntax is bad.

Tables syntax is worse.

No table of contents.

You can't have variables.

You can't include another file.

In the end, every website does its own markdown because Markdown sucks.

Interopability? Ah ah. Some have tried. That's a rabbit hole to get into.

In the end, Markdown is just a starting point... To a real format like Asciidoc.

Do you have a suggested improved syntax for images and tables? I think Table of Contents exist in some implementations of Markdown but it’s not common.

Yes I have!

I am gradually switching to Asciidoctor because it solved all the pain points I cited (and more)

> Table of contents

That's simply :toc:

> Images

Doing better is easy, plain HTML is better than Markdown.

For example:

  image::sunset.jpg[]

or [link=https://www.flickr.com/photos/javh/5448336655] image::sunset.jpg[Sunset,300,200] or Click image:icons/play.png[Play, title="Play"] to get the party started.

https://asciidoctor.org/docs/user-manual/#images

> Tables

See https://asciidoctor.org/docs/user-manual/#tables

What I need is something that let's me write my docs in markdown and then quickly and easily render them to PDF with nice output, runs on Linux, and doesn't render remotely.

I've used Grip, and I use the Markdown to PDF plugin in VSCodium but none of these really meet the requirements.

Asciidoctor has no problem rendering files to PDF.

You can convert your source markdown files with https://github.com/asciidoctor/kramdown-asciidoc

Thanks I'll take a look.

At least for installation on another distribution it doesn't suggest you to install apt-get.

http://support.typora.io/Typora-on-Linux/

It's almost perfect. The minor but irritating problem with it is that I can't seem to use my own fonts in the editor; the selections for the editor and code fonts are fixed. Worse, if I manually edit ~/.config/marktext/preferences.json and change editorFontFamily and codeFontFamily to my preferred fonts, Mark Text fails to launch at all, whining that they "should be equal to one of the allowed values".

Like, what gives? Why restrict this? It obviously ain't an Electron limitation, since plenty of other Electron apps support my fonts just fine.

This new version 0.16.0 will support more fonts, and will be released in the middle of this month.

Does "more fonts" mean "any font installed on my system"? Or does it mean "a bigger hardcoded list of fonts"? If the latter, will that list include Computer Modern?

This is really nice, but I find whenever I try one of these types of apps to type or edit real text for more than a few minutes, I find myself wanting pote (plain old text editor) features. The first thing I miss is generally line-moving, but more accumulate to the point where I eventually move back to my favoured pote of the moment.

As a Typora user, I'm glad that this editor includes a table of contents area in its sidebar. I had to dig into the docs to find that it does indeed have this. ToC navigation helps me so much for being/getting organized.

seems better than typora though I miss the file-system-layout on the left side when I have a lot of md files.

one thing I like to have for both is the vim key bindings, so I don't need use up-down-left-right keypad to move cursors, for example if I type bold the editor will auto match to be bold which is nice, but I still have to move my keys to skip the two just added, in fact many editors provides autocomplete or bracket complete but they do not provide a way for me to skip the stuff they added easily, or I must be missing something basic here.

The website is broken for me on mobile (iPhone 11 Pro Max).

I've tried looking the website on my iPhone SE with Firefox. Sadly the website isn't responsive at least on my phone.

I switch between this and Zettlr, they each have their small annoyances depending on what you're doing.

Tried Zettlr, but couldn't get it to work.

Site looks like a disaster on mobile.

which apps support full embedded HTML? I like markdown but I run into exceptions where I need some html all the time. It could be a short span for color or an iframe for an example and most libraries and apps seem to fail there.

Downloaded. This one fails like most do. Sigh...

That wouldn't be Markdown though?

A better question might be, what flavor of Markdown serves your purposes? Find this, and then look for an editor which supports it.

Adding anything non-standard would be creating a new flavor of Markdown. I want for all the features I use in an editor to be fully portable. If it's not standard, then it's not portable.

NOTE: In this case, by Standard, I mean widely used.

I get what you are saying though. You want the full versatility of HTML at some point. My method of dealing with this is to come up with a set of scripts which converts snippets and turns the doc into HTML. The Markdown file would be the source and the HTML would be the view layer. The scripts are a build process. Of course, this takes time which not everyone has. It's impossible to cover the use cases for everyone though. And I find so often that when I get a feature I think I can't live without, it still falls short because I didn't think through my problem well enough.

Otherwise, it might be best just to use HTML from the start. Or you could ditch Markdown and try Asciidoctor. The issue there is that you're limiting your editor options.

https://asciidoctor.org/

html has always been a part of markdown. It says right in the original spec

> Markdown is not a replacement for HTML, or even close to it. Its syntax is very small, corresponding only to a very small subset of HTML tags. The idea is not to create a syntax that makes it easier to insert HTML tags. In my opinion, HTML tags are already easy to insert. The idea for Markdown is to make it easy to read, write, and edit prose. HTML is a publishing format; Markdown is a writing format. Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text.

> For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.

and

> Span-level HTML tags — e.g. <span>, <cite>, or <del> — can be used anywhere in a Markdown paragraph, list item, or header.

https://daringfireball.net/projects/markdown/syntax#html

The entire point is just to make most of the document easy to read. Not to replace nor forbid html.

You're right, I guess I just haven't used Markdown like this. My usage has mostly been within plain text editors which have the limitations you're talking about. I don't personally find the need for including HTML in my Markdown documents, but I can understand this expectation since many have known Markdown from (for example) WYSIWYG editors which do handle a mixture of formatting types.

Nooo, another Electron "app"

What does it do better than the oldest simple and elegant markdown editor, vim?

Reply on news.ycombinator.com