Don't like displaying the same content twice either. It gets a bit old mentioning Obsidian all the time, but their source code view is very close to the rendered view. This, and Typoras approach, are two good solutions to avoid split screen.
I wonder if there are more ways to solve that problem.
Personally I hate when editors try and make my markdown look like anything but plain text. Syntax highlighting is fine, but I don't want you to make my font bigger when I type # and I don't want my text to be italicized when I type an asterisk, etc. Plain text has a purity and simplicity to it, and if I wanted those features I would probably just use MS Word or Pages or something.
I don't personally find the preview to be distracting, and I like seeing the rendered product with a distinct separation from the code that generates it.
I don't think I'll swap to this since I'm relatively happy with just having MacOS preview and a terminal in a workspace split, but I could totally see why someone would like this.
Some places have a healthy mix. GitHub will bold and italicize the text to suggest the rendering of certain blocks, without changing font sizes. Good for reducing the need to swap between edit and preview to verify simple formatting issues as I write.
What I truly despise is when markdown blocks are parsed immediately, where the delimiters are instantly removed and the text gets formatted into a terrible WYSIWYG editor. It causes me to constantly swap mental models as I write. It’s the worst of both worlds.
This is neat looking! I don't have loads of experience using markdown editors, but the 2 features which i think really attract me to wanting to use it are:
1. Exporting into soooo many formats (thanks to pandoc).
2. Importing into this app from other formats. The associated website briefly talks about importing a Word doc (working on it distraction-free, and then re-exporting as a doc file format), which seems a little bit of an edge case *for my workflows* but the fact that it is possible i think is/could be really handy!
I think i'll give this a try. Kudos for releasing this!
My distraction-free Markdown editor is vim. No UI clutter, not an electron app, loads ginormous files super quickly, is powerful when you need it to be and simple when you don't.
I use Goyo for the minor convenience of limiting the column width, but really it's all I need.
Why do we see so many markdown editors? Is there some library or widget out there that everyone starts from to parse and render markdown, and then it just turns into a simple exercise of putting a UI in front of it and adding a tiny number of novel features? I can’t understand why so many people keep producing basically the same application with tiny variations to edit and view what is a relatively simple structured text format. I sort of remember from the 80s the quick and dirty app that you could find many of variants of for Commodore, Apple, and PC systems was a recipe database, largely because it was an easy exercise. Is the markdown editor todays version of that?
I believe that markdown editors belong into a certain group of software, which are seemingly simple, but people are for some reason pretty picky about features, UI, and so on.
Other members of this group are music/media players, simple organization tools (e.g. time-tracking, to-do), and of course coding-related text editors. I think I had one or two more examples, but don't remember right now.
And this leads to a lot of tools being very similar on surface.
There are a lot of features which a markdown editor can have which are somewhat difficult to implement and get right, such as WYSIWYG with css theming, support for latex equations, support for nonstandard features like Pandoc markdown, plugins, support for the textbundle format... Nothing exists that implement these perfectly and so I think people make attempts at making something that at least works for their specific use case but no one can make the one true editor that does everything because it would be a huge amount of work.
I like composing drafts in Markdown but I have to export them (to PDF to view and mark up in Remarkable, to Word to share with some people and so) quite often, and going into pandoc and remembering the commands adds extra layers.
This is a huge contribution.
p.s. because this is Hacker News, I hope some smart person is going to point out an even more efficient way to switch contexts. I am here for it if it doesn't involve trying to learn emacs for the 87th time.
I would recommend finding out how to execute a shell command in whatever editor you use, and then write a script that does the exporting with the settings you care about. Then bind a command in the editor to that renderer.
Not emacs but not that different either; I personally use tmux with Vim on the top pane, and a split with the command line on the bottom, and a workspace split with Apple Preview on the left. Here is a sample of it: https://i.imgur.com/oqss6SO.png
It's not for everyone, but I can't think in anything but Vim now.
The "distraction-free" bit reminded me of a similar tool I used a couple of years ago, Ghostwriter [0]. Differences between the two AFAICT:
- use of Pandoc as a converter is only optional in Ghostwriter, and I don't know how well it is integrated
- semi-official MacOS support: Ghostwriter requires you to build the app from source (maybe its authors didn't want to notarize the app?) and it has a few quirks apparently[1].
- more features for the more mature Ghostwriter.
In any case good to see more choices in this space, cross-platform Markdown word processors with Pandoc support were a rare occurrences a couple of years ago!
I was so crushed to see that this is an Electron app. I'm a longtime iA Writer craving built-in Pandoc export, and this is basically my dream app. I just can't get behind running all of Chromium to support a minimalist text editor.
OTOH, being an electron app means there is Windows support from day one. Windows is sorely lacking in Markdown support relative to what's available on Mac.
Markdown by design allows arbitrary HTML, so every markdown viewer at a minimum needs to support the entire HTML, CSS, etc. DOM. It's easiest (and likely more secure) to use something like Chromium.
I get that, and I'm not disagreeing. However, two points:
1. I think writing-focused Markdown editors should not feel obligated to render arbitrary HTML in their previews. The format may support it, but the editor doesn't need to—one of the great things about Markdown is that your editor can be anything from vi to VSCode.
2. On the Mac, there is an extremely easy API to display a WebView (WKWebView), which would cut the size of this executable to roughly 1/100th of its current size, drop the memory usage, and reduce energy consumption. You can even keep most of the business logic in JavaScript if you want.
I've been using Zettlr for the last few days, and I've fallen in love with it. The best feature that it has for lecture note taking is that you can paste in screenshots and it automatically handles it for you, putting a file in the right place and linking to it.
If you tweak the Emacs "face" settings for Markdown to be mostly-WYSIWYG (plus some gray markup characters), it's pretty nice and low-distraction.
Headings are large and fixed-pitch, bold is bold, italic is italic, link text is underlined and blue, link URLs are gray, bullet asterisks are bold, no angry fruit salad color schemes, etc.
Another contributor to this mostly-WYSIWYG is that *M-q* (`fill-paragraph`) works well.
I understand a utility of a specialized and featured editor. However, in case of Markdown, it seems that it was meant to be handled in whatever editor user edits/reads text files. This way it can be both written and read anywhere. It's just structured text.
If anything, a Markdown "viewer" or HTML-preview is what was usually a requested/expected feature. So that the simplicity of Markdown could be leveraged for authoring web-pages. But this could be done with a browser plugin, as well.
Many text editors these days have some ways of visually highlighting Markdown elements in the text, just as any other syntax highlighting. In my experience, another editor just for Markdown is an overhead.
LaTeX/MathJax could be written in more dedicated editors, as it's really not Markdown, and as much as it's convenient to keep everything in the same text file, complex formulas are not easy to visualize in text without rendering. And if indeed such a mixed "Markdown" file needs rendering, then it's rather a source file which asks for some Makefile to automate the assembly and rendering, rather than asking for another full-blown editor with its internal rules and options.
40 comments
[ 0.22 ms ] story [ 103 ms ] threadMy markdown editor needs to be just one combined edit/preview window. Either with Typora like WYSIWYG or some syntax highlighting.
I wonder if there are more ways to solve that problem.
I don't personally find the preview to be distracting, and I like seeing the rendered product with a distinct separation from the code that generates it.
I don't think I'll swap to this since I'm relatively happy with just having MacOS preview and a terminal in a workspace split, but I could totally see why someone would like this.
What I truly despise is when markdown blocks are parsed immediately, where the delimiters are instantly removed and the text gets formatted into a terrible WYSIWYG editor. It causes me to constantly swap mental models as I write. It’s the worst of both worlds.
100% agree on the instant-rendering. That is always the first thing I disable in Slack.
But I think you mean combined edit/preview like Zettlr has, where it's a hybrid.
Pulls in two pretty huge dependencies though, electron and pandoc.
1. Exporting into soooo many formats (thanks to pandoc).
2. Importing into this app from other formats. The associated website briefly talks about importing a Word doc (working on it distraction-free, and then re-exporting as a doc file format), which seems a little bit of an edge case *for my workflows* but the fact that it is possible i think is/could be really handy!
I think i'll give this a try. Kudos for releasing this!
I use Goyo for the minor convenience of limiting the column width, but really it's all I need.
https://markdown-it.github.io/ https://github.com/markdown-it/markdown-it
Using Haskell, you could of course use Pandoc directly ;)
https://hackage.haskell.org/package/pandoc-2.17.0.1/docs/Tex...
https://hackage.haskell.org/package/pandoc-2.17.0.1/docs/Tex...
Other members of this group are music/media players, simple organization tools (e.g. time-tracking, to-do), and of course coding-related text editors. I think I had one or two more examples, but don't remember right now.
And this leads to a lot of tools being very similar on surface.
It works better that way for me.
-- There are ("too"?) many Markdown editors
-- This is exactly what we need.
I like composing drafts in Markdown but I have to export them (to PDF to view and mark up in Remarkable, to Word to share with some people and so) quite often, and going into pandoc and remembering the commands adds extra layers.
This is a huge contribution.
p.s. because this is Hacker News, I hope some smart person is going to point out an even more efficient way to switch contexts. I am here for it if it doesn't involve trying to learn emacs for the 87th time.
- https://github.com/OliverBalfour/obsidian-pandoc
- https://packagecontrol.io/packages/Pandoc
- https://marketplace.visualstudio.com/items?itemName=DougFink...
Not emacs but not that different either; I personally use tmux with Vim on the top pane, and a split with the command line on the bottom, and a workspace split with Apple Preview on the left. Here is a sample of it: https://i.imgur.com/oqss6SO.png
It's not for everyone, but I can't think in anything but Vim now.
- use of Pandoc as a converter is only optional in Ghostwriter, and I don't know how well it is integrated
- semi-official MacOS support: Ghostwriter requires you to build the app from source (maybe its authors didn't want to notarize the app?) and it has a few quirks apparently[1].
- more features for the more mature Ghostwriter.
In any case good to see more choices in this space, cross-platform Markdown word processors with Pandoc support were a rare occurrences a couple of years ago!
[0] https://github.com/wereturtle/ghostwriter
[1] https://wereturtle.github.io/ghostwriter/download.html#macos
edit: formatting
I would like a markdown editor that supports pandoc in full. I think sciter would be a better option than electron though.
1. I think writing-focused Markdown editors should not feel obligated to render arbitrary HTML in their previews. The format may support it, but the editor doesn't need to—one of the great things about Markdown is that your editor can be anything from vi to VSCode.
2. On the Mac, there is an extremely easy API to display a WebView (WKWebView), which would cut the size of this executable to roughly 1/100th of its current size, drop the memory usage, and reduce energy consumption. You can even keep most of the business logic in JavaScript if you want.
Uncaught Exception: Error: write EPIPE at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:98:16)
Headings are large and fixed-pitch, bold is bold, italic is italic, link text is underlined and blue, link URLs are gray, bullet asterisks are bold, no angry fruit salad color schemes, etc.
Another contributor to this mostly-WYSIWYG is that *M-q* (`fill-paragraph`) works well.
If anything, a Markdown "viewer" or HTML-preview is what was usually a requested/expected feature. So that the simplicity of Markdown could be leveraged for authoring web-pages. But this could be done with a browser plugin, as well.
Many text editors these days have some ways of visually highlighting Markdown elements in the text, just as any other syntax highlighting. In my experience, another editor just for Markdown is an overhead.
LaTeX/MathJax could be written in more dedicated editors, as it's really not Markdown, and as much as it's convenient to keep everything in the same text file, complex formulas are not easy to visualize in text without rendering. And if indeed such a mixed "Markdown" file needs rendering, then it's rather a source file which asks for some Makefile to automate the assembly and rendering, rather than asking for another full-blown editor with its internal rules and options.