Panwriter – Distraction-free Markdown editor with pandoc integration
panwriter.com
panwriter.com
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.
My 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.
I use Goyo for the minor convenience of limiting the column width, but really it's all I need.
- 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.
-- 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.
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.
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.
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.
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!
Uncaught Exception: Error: write EPIPE at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:98:16)