Typora – A cross platform markdown editor | Hacker News Reader

Typora – A cross platform markdown editor

typora.io

Having just installed SolveSpace, a parametric 3D CAD tool which includes a solver in 1.9 MB, I can't help but feel a bit sad when a minimal Markdown editor is a 34 MB file :(

I wonder if there's a better option for crossplatform apps than Electron. Maybe Rust? Or Python+PyQT?

Still less than Google's site for the new Pixel [1] :)

[1] https://tools.pingdom.com/#!/ckhRCy/pixel.google.com

I would like to see what is the size of this page in countries with slower internet.

I would guess they don"t care. These countries are not exactly the target market for such a expensive phone.

It costs $2.60 to view the website in Canada with non-retina images.

Source: https://whatdoesmysitecost.com/test/161007_QR_78c23294113b6c...

97.7% of which is images. Also, PageSpeed gives it a 48/100 on desktop.

Why the heck are they using PNG for a large photo panorama? That's 5MB right there for one image.

I think we've lost the binary size battle, just as we've lost the bandwidth battle. I agree, there has to be a better way, but development convenience is being prioritised.

And we've lost the dynamic library battle. I understand why but can't help being saddened by it, it was such an elegant solutions.

Elegant in theory maybe, rough in practice.

I'm really glad we're finally starting to win the dynamic library battle; it was a kludgey fix for a transient storage bottleneck that has been plaguing us with unnecessary complication for at least a decade now. Predictability is a good thing.

It's not such a good thing to have to update each and every application whenever there is a vulnerability in a library.

Meh, I feel like it is even better because even if you could update the library indvidually you have no idea about the ramifications of such an update and what potential other vulnerabilties/bugs doing so will uncover.

You could install the electron or nw.js runtime separately and then just download/distribute a compressed file with the JavaScript source code. Witch would be smaller then most programs.

Why do you say "lost"... Technology brought us an orthogonal solution to the problem, but yet, it is a solution :-)

Maybe one day, when we'll run out of whatever-it-takes to build computers, we'll have to optimize for size, but that's another story.

I still remember the days of C64 and the 640kb limitation in DOS. What we got was first optimization then full on hacks and mostly assembly language.

To use a tool and give up on size really doesn't bother me. I rather have elegant solutions then full on hackery or difficult memory management type solutions.

I don't think so, have we? Windows applications are very small because all the UI libraries are in the OS itself, where they should be.

While I agree and upvoted you, I think the realistic answer is that the alternative to this 34 MB editor is no editor like this at all. The author made what they wanted with the tools they knew.

You seem to be contradicting yourself.

If the binary size is big because of the (lack of) tools the author knows, the alternative to this is an editor made by someone who knows tools that don't bloat the binary.

He's not.

This exists because the tools existed to enable the author to make this in a reasonable timeframe/effort.

If something better/smaller exists, use it. If it doesn't exist, it might be because making it smaller requires tools that take more effort/time to use and thus no one has bothered.

I've traditionally liked crapping on bloated software too, but have come to realize that the plethora of software is fine and I can use whatever I like and abstain from what I dislike. The simple fact is that the alternative to bloated software is a subtraction of that software. And sometimes they happen to be useful, despite their size.

Thanks for sharing this point of view, man.

I am not really crapping on bloat.

I am merely correcting the point that the only alternative is no editor at all.

On your first point; alright, then my mistake.

But my comment was really in response to your second line here. I disagreed with your assertion. The alternative is that this editor doesn't exist, meaning "no editor at all" with this specific featureset/design/etc. And if this editor is better than a less bloated editor, why shouldn't it exist?

I agree with you, I just think we need to find/publicize/develop a better solution for writing lean applications for the desktop. It's really sad that our easiest option right now is something that results in a 35 MB distributable package.

i wish D had good, complete qt bindings. it seems like the best option for a new standard compile-to-native desktop gui app language. i have a personal preference for ML-family languages, but i think those have already lost the war for mindshare; D on the other hand is solidly C-family and therefore familiar, but is a way more pleasant language than C++.

D's binaries still aren't small[0], what with including the entire prelude without code elimination.

Sure, they seem tiny alongside Electron, but a giant doesn't look big next to Jupiter.

Nim competes in the same space, and seems to hit this problem a whole lot nicer. [1]

[0] http://forum.dlang.org/thread/yhcopkgdkhclbkfpisut@forum.dla...

[1] https://hookrace.net/blog/nim-binary-size/

I do agree with everything you said, but a) I'd still rather the giant than jupiter and b) Nim still has a long way to go to prove itself. Just like D, it is in the awkward position of being high performance without fully addressing either the performance or safety concerns of the preceding languages. This may be an acceptable tradeoff but neither have any killer features that make it an obvious good fit for a given problem. Rust has memory safety-like, actual memory safety-and go has utter simplicity. What is the Nim two word pitch? Small binaries isn't going to win anyone; that's what deflate is for. Meanwhile, you don't have the language stability and, erm, prudent design that D has hammered out for over a decade. Even if I don't agree with the decisions I can't say D has executed poorly.

Nim though? Who knows! I've never seen it in production, so I can't tell the downfalls!

Absolutely agree on a.

I think the popularity of Electron is a travesty.

I live in Australia, but despite it being a first world nation, the Internet speed is miserable and bandwidth is precious. (I pay $50 a month for 100gb, at 1.5mbms). Size still matters.

I do quite like D and the structured process of developing the language they use.

But I also find it incredibly depressing that Nim has a better optimising compiler.

> What is the Nim two word pitch?

Metaprogramming. The best metaprogramming anywhere.

What about Lisp-family languages' metaprogramming capabilities?

i'm pretty sure the racket folks would take issue with that (:

SolveSpace looks exactly like the sort of "user-unfriendly" tools I build for myself and am absolutely personally productive on but would never release to the general public. Maybe I need to re-think this ;)

That said I'm getting back into GUI editors. Anaconda for research computing. And Atom for text and code. Including Markdown.

The advantage is Atom's module system. 5000+ third-party creations. Including really edge cases. That, I believe, is due to the reach of JS/HTML/CSS.

It's very very not user-unfriendly. I finished the tutorial in 20 minutes and it was very intuitive and exciting!

That's a good question. If I want to write a cross-platform tool I wouldn't know what to choose either (besides electron that is).

Maybe Xamarin?

Qt is not bad. I got interested in libui (https://github.com/andlabs/libui), but it stalled a bit, after a couple of months of very promising activity.

Very different beasts. :) Writing CAD software can be done with a surprisingly small number of libraries, which is not at all withe case when it comes to typesetting.

Really? That's very surprising to me. Doesn't the OS include everything required to display text already?

Go+QML worked okay-ish for me in a few brief tests. While Go tends to make large-ish binaries, it's not nearly as bad as Electron.

go-qml and forks don't support Go >1.6 due to the cgo breakage; some manage to compile, but with a memory leak.

There's github.com/therecipe/qt which is a full Qt binding (not just QML). You have to set-up a proper dynamic linking build process if you don't want 100MB binaries though, and the bindings require a default Qt installation or a folder full of symlinks to fake one if your Linux distro splits Qt in different folders.

Python+Qt is very nice to program with. Portability is nice between Windows and Linux (that's my experience)

But binary size is big :-) The Qt libs are not exactly small nor is the python interpreter.

Yep, I was stunned when I realized the total distribution size for a tiny script I wrote that used numpy+scipy would run over 300mb. And here I thought Electron apps were big...

If creator reads this: I note that its currently free and in Beta. What is the expected cost, and the transition from a beta client to the paid one? e.g. can I just stay on beta forever and only pay if I want to upgrade to get the new features? etc. Looks very nice so far!

For those who check comments first...

I use this daily on macOS and it is a fantastic user experience. The Markdown editor doesn't have a separate preview window. It auto detects your blocks and toggles between editing and rendering. Overall very polished. It has Mermaid ASCII diagramming support, which I love, but I wonder whether the diagrams should be imported images since you would need Typora in order to see it rendered.

Reminder that it is still beta. I'm still hoping for a more unified Evernote-ish side bar since right now it depends on using a file browser of some sort, with no built-in search across notes.

FoldingText.app on OSX and "usecanvas.com" on the web work similarly.

I really like that editing model for markdown. (Hiding all the markup except that which is surrounding or adjacent to the cursor.) I'd love to see someone implement it on top of draft.js or something. (I haven't gotten around to yet myself yet - too many projects, too little time.)

I'd love to see it as a renderer for source code comments. I'd love to have th jupyter experience in an actual editor.

We're doing something similar on riot.im with our new editor.

How does it handle images? Can I drag'n'drop images and will they just be linked or saved to a place relative to the document?

I just tried it. You can drag images into the doc and it will show the image WYSIWYG, but the image url looks to be an absolute path, not a relative one.

It does not move the image.

I think I may be missing the main usecase here but how come I see so many different markdown editors on here all the time? Markdown is pretty simple and easy to read in plaintext, or with simple highlighting so what's the point?

Or am I just being one of those weirdos that's like "WHO NEEDS SYNTAX HIGHLIGHTING YOU SCRUBS!"?

For me it works well because of:

- Spellcheck

- WYSIWYG for complex/annoying markdown (try adding a column to a 20 row table in markdown unassisted)

- Nice unobtrusive typing experience

- Easy toggle switch to raw markdown (Ctrl + /)

- Syntax highlighting for code blocks

- Familiar hotkeys for formatting (Ctrl + B for bold, Ctrl + 1 for H1, Ctrl + 2 for H2 etc...)

> Markdown is pretty simple and easy to read in plaintext

That is actually the main reason for markdown's existence [1], so I have the same issue with these editors. I don't understand attempts to hide the formatting.

"The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions."

[1] https://daringfireball.net/projects/markdown/

I often like to preview how text works as I work on it.

e.g. if I bold this, does it look out of place or to check that internal links work.

However, I currently just use my normal text editor and open the output in a browser (if compiling to html)/terminal (if compiling to man pages)/evince (if compiling to pdf)

Markdown is simple and easy to read to coders, and others with (for a lack of a better term) mathematical inclination.

It would be really awesome if we could get the current "Word for everything crowd" to use markdown too, and assistive WYSIWYG editors are a lot more attractive to them.

Just wildly speculating here (with some wishful thinking thrown in): maybe the intent is to indirectly encourage non-technical audiences to use git-based, public version control for authoring public and frequently revised documents.

For instance: imagine if federal legislation, and amendments to federal legislation, were published in this manner. You could examine diffs to see how passed (or proposed) amendments altered (or will alter) the law. You could even have a 'git blame' sort of feature that let you to see which members of congress voted for or against particular amendments. It would definitely aid political transparency, and make it easier for the public to participate in the legislative process.

Eh, I guess that's mostly my wishful thinking...

I see no reason for this being wishful thinking, other than the part where you'd need to be 30+ years in the future.

Wouldn't it be easier to add stronger version control (think track changes) to gui document editors?

Maybe. But I guess my hidden objective here would be to open up the legislation making process to the public. At the moment (at least in Australia), the best we can do in this regard is 'exposure draft' consultation.

Basically a draft of the legislation is put on some consultation website, and people can send in big long essays via email. The participants don't see each others' comments, it's just a 1-1 type relationship between the government department and the 'consultee'.

I'd like to see infrastructure that would allow:

(a) consultation participants to see and comment on each others' suggestions (think Greenpeace commenting on Shell's submission regarding fuel tax credits, and vice-versa); and

(b) for participants to be able to make pull-requests, forcing the government department to answer in the positive of negative and give reasons.

On the second point, under the current system they can simply put your submission through the shredder if they don't like your suggestions. By making it very public, government departments will feel strong pressure to acknowledge and respond in a reasoned way. Many government departments do a big song and dance about 'transparency'. I think this provides a concrete and actionable way to significantly increase this wonderful 'transparency' thing that I hear so much about.

Being able to see what I write the same way as a reader would helps me empathize with them. Perhaps now I can have just one window open instead of Sublime Text + Marked.

I read the page a few times through and I can't find answers to a couple questions. If someone has already installed the app, can you clarify:

- When I save the document, is it just plain markdown as text?

- If I copy and paste it into an input element in my browser that expects markdown, will it be copying just plaintext markdown?

- What if I copy and paste it into something like Microsoft Word?

If the creator is listening, I have some comments for your site:

- I tried clicking/typing on the opening page before realizing I had to scroll down.

- I eventually found that there were some clickable words that changed displayed images, but it wasn't obvious.

- After finding I could click some words, I expected to be able to click the menu options under 'Accessibility' and found it a bit ironic that they weren't clickable.

On the positive side:

- The moving image showing a user typing markdown in and the text transforming is awesome and looks great.

This looks pretty but I can't see myself using it much, I'm usually writing markdown in vim.

Anyone know of a vim plugin to split the window to a live preview for markdown? It is pretty much readable as plain text, but it would be nice to see a preview to know if I've made an error in the markup.

- Saving is as plain markdown. But you can export to a variety of formats (they use pandoc)

- There is a setting for copy/paste to use markdown vs plain text

- Pasting into word would be as HTML since word is rich text

> - There is a setting for copy/paste to use markdown vs plain text

Do you mean markdown vs rich text? Or can it paste markdown, plain text, and rich text?

No, the setting is Preferences > Editor > Default copy behavior

When i turn it off (default) and copy/paste into notepad it only pastes plain text with no markdown.

When i turn it on and copy paste into notepad it retains the markdown formatting characters (*'s, ```'s and etc...)

Pasting into MS Word (a rich text editor) always pastes as rich text regardless of the setting

Shift-[Cmd/Ctrl]-C seems to always copy markdown plaintext.

Your questions lead me to believe you would be someone ideal for trying out their beta and providing your feedback.

NOT CROSS PLATFORM

Linux User Here. (I am actually an OpenSUE and Arch user) when you think providing an Ubuntu solution https://www.typora.io/#linux and have

sudo add-apt-repository 'deb https://typora.io linux/'

this does not make this a Linux platform solution. Currently I think

1) Provide a RPM and a DEB

2) Provide a tar ball of the source so it can be compiled

3) Using a Linux application installer like flatpak, appimage or snap would also make it acceptable to me instead of RPM/DEB

Thank you for your work but being on Linux isn't simple and I don't think it is accurate to say cross compatible on Linux when all we got is a deb. Hope that in the next 3 years it gets easier.

The best solution I believe for providing packages for multiple of distribution is SUSE Build Services https://build.opensuse.org/. It provides the ability to build once and SUSE build solution will make packages for other distros. So it will make a deb, rpm and you could even have a package for Arch.

https://en.opensuse.org/openSUSE:Build_Service_Tutorial

RHEL / CentOS user here... I feel the same

FWIW, electron-builder even offers to generate Debian, RPM, Arch and plain tar packages simultaneously. So there's really no reason not to offer all.

So then the ability to provide all three is even simpler?

Assuming typora uses electron-builder (which most electron projects do), then it's just a config setting for their build pipeline, yes.

There's an AppImage available which you can use to install it on any Linux Platform. I'm not sure how updates work for that though

https://bintray.com/probono/AppImages/Typora/0.9.19.glibc2.1...

Very pretty. I like how it hides the markup, but still feels like you are editing markdown (e.g. <Backspace> removes the hidden formatting characters).

Unfortunately, there is quite some input lag for me (Windows 10, reasonably fast laptop, HighDpi (Yoga Pro 2). I have this in many Electron apps, some less (Simplenote is very snappy, VS Code is OK), some much more (Atom), but it almost alway feels wierd.

Looks nice but isn't the point of markdown pretty much that you can still do your typing in clear, explicit plaintext and then merely generate properly formatted html/pdf/whatnot from it, effectively avoiding any wysiwyg editing?

That's what different mark-up languages such as SGML (HTML/XML), LaTeX, even Org mode, etc generally try to achieve: to separate content and presentation. That is, to write the meat of the text explicitly and not even able to worry about how it will look.

View > Source Code Mode

Yes and no. The point of markdown is that it is human readable both plaintext and rendered.

Writing in a rendered environment looks nice, which to some people foster writing.

Writing in a rendered environment ensures your markup is correct ( as it wouldn't render, if it wasn't)

For me, those two things ensures that I don't have to worry about how things look when I write.

No plain download for Linux available.

Just a Debian repo.

Not open source, apparently.

Looks quite nice though. I'd try it out if I could install it on Arch...

There's a page[1] detailing how to get get the .deb file without apt, and then use dpkg for arch [2] to install it if you wanted to. Of course you'd have to manually update, and pacman won't know about it.

[1] http://support.typora.io/Typora-on-Linux/ [2] https://aur.archlinux.org/packages/dpkg

EDIT: Turns out there is an AUR package already: https://aur.archlinux.org/packages/typora/

Good catch.

Serves me right for just googling for "aur typora".

I found this a little annoying myself. Lately 'Linux' somehow only translates to 'Only Debian/Ubuntu'.

However, this is the first one I've come across that doesn't even distribute plain old gzipped binaries.

I've been using Typora for several months now. It's the best native markdown editor I've found. Extremely smooth to write in preview mode using markdown notation. Inline math support is nice, but I wish it had block/equation math support. Code highlighting, table support, and YAML front-matters are also great. I love being able to switch between source and preview with command+/.

It does, just look under paragraph.

Not OP, but whenever I enter Latex into the math block, nothing ends up getting saved?

With everybody scrambling to support markdown, I'm surprised there isn't more support for org mode. Once switching to it I can't go back.

I want to love org mode, but I don't know it well enough. I've only seen a video that reviewed how great it was, but I haven't seen any tutorials/videos on how to actually use it that went into detail.

Any pointers on getting started.

I used to use Haroopad [1] unfortunately the author seemed to stop its development some time ago. This seems like a good alternative, in fact, it looks and works so well that I can justify its dependency on Electron. Props to @abnerlee for its work. I will definitely recommend this application to my friends.

[1] http://pad.haroopress.com/

I just found Haroopad myself a couple weeks ago, but did note its lack of updates. I may try out Typora for comparison. That said, Haroopad seems to work pretty well for me at the moment.

Fool that I am, I stared at the page for quite some time wondering when the loading animation was going to end and the page load. Then I saw the scroll bar...

There's also a little downward-pointing arrow at the bottom, but I agree the design is unintuitive.

The windows download page does not have a way for you to go back to the main page... Not even clicking back in the browser.

Well, there is the "Typora on Mac" button on the top right, which oddly enough does take you back to the homepage. But who would think to click that?

Looks nice. I've been using Writemonkey for a few years, but might consider switching to this if the price won't be too high.

The showstopper for me, at the moment, is the non-international spellchecker. I need my native language (Norwegian).

I would also like the option to have a tiny clock in the bottom right of the page (like Writemonkey has). It's useful for fullscreen writing.

Writemonkey is probably the best alternative for Windows. It has way more features, and it's free (unless you need plugin-support). It does not, however, have inline live preview.

It's a little laggy when I'm typing, I keep notes for my whole class, not one file per lecture so the files are decently big. I have found all markdown editors with live preview have this same problem as they redraw on every keystroke and this is fairly slow process with a big document and slow computer. My note taking laptop is not very powerful.

This program looks great and I really want to use it, so I may need to start creating a new notes file for every lecture and then using a script to combine them later and export to PDF.

Nice tool. Like it. Especially like the fact that it does syntax coloring for different languages. There is nothing like this as far as I know. Usually Markdown editors are not WYSIWYG.

Does this only support GitHub-flavoured markdown?

I didn't find the website very informative (honestly, confusing if anything), and couldn't find reference to anything else, like Asciidoctor.

I like it. Used it for >several months. If you have used mou before it is similar. You can edit the themes (ive downloaded some from github) and you can configure a couple markdown flavors out of the box iirc.

It renders in place in real time unlike some of the ones that load on half of the screen.

Worth a download. They smoothed out a lot of the issues with updating content & cursor movement.

Best markdown editor ive used, if viewing the rendered markdown matters to you. You can export as a pdf and a couple other doctypes which is nice for sending to non-technical teamenbers who have no markdown reader.

Any idea if it works with Asciidoctor?

Not familiar with that. Probably not. Its a few MBs of diskspace & works out of the box. Prob be quicker to dl & dump it if you dont like it.

All editors/notes/workflow are highly subjective, i tried macdown, mou, a bunch of similar os x notes clones, notes, evernote, ect.

I like this for notes & simple docs. I would really like it if it had a sidebar with directories but the reason so many of these things exist is that everyone angry enough just builds their own.

According to their docs they use Github-flavored markdown. But they also apparently support lots of extensions to it.

See here http://support.typora.io/Markdown-Reference/

And here for other docs http://support.typora.io/

Huge fan of Typora. My one issue is with line breaks. I like to edit GitHub README's directly in Typora and add line breaks around the 80 character mark, but Typora's window seems to wrap them differently.

For example:

- README on GitHub: http://i.imgur.com/pq581xN.png

- README in Typora: http://i.imgur.com/oYnyzMJ.png

I posted a support ticket, and the developer responded that "the difference is that Typora will render single line break, while Github will ignore those single line break". That's fine, but GitHub parity seems like a top use case, so AFAIK this remains an open issue.

I have been using Typora for the past 6+ months. Love it!

Best markdown editor for my needs. Its simplicity is its best feature.

Yikes this is massive - is it a JavaScript site embedded in a frame by chance?

Electron does a bit more than that (full-blown nodejs in background), which of course only increases the footprint. But apart from the final binary size, it's an okay-ish development to work with. Especially for rapid prototyping.

(Disclaimer, shameless self plug: I wrote a blog article on it: https://news.ycombinator.com/item?id=12651601 )

I just installed this and what I found was that it works nicely but, at least on OSX, it renders correctly but doesn't copy # or ## elements during a copy / paste operation. It correctly saves them to do disc but doesn't put them in the paste buffer. Pity. Its a pretty app but if they got that wrong, I wonder what else is lurking.

I don't need another editor that writes files. I could, however, use something I can paste markdown into, fix a formatting issue, and move back to a text buffer in a browser / Github readme, etc.

Update: I just dug into it some more and there is a specific Copy to Markdown (shift+command+c) command so that does make it a bit more interesting for me as a command+tab paste / fix / shift+command+c way of debugging markdown hell. Apologies for the initial error.

If you just select all and copy a lot of formatting is lost. However, you can go Edit > Copy As Markdown (shift+cmd+c) and that keeps all formatting, even headings

I just tested a use case of:

* paste in a Jekyll formatted markdown document * select all (which it couldn't do with something of 3,103 words - I had to do it manually) * shift+command+c to copy it as markdown * paste it into a TextMate window * The initial ---- markup to denote the header block is missing * The tags: [] array statement is converted into a header

I hope the author notices; it really is pretty.

This is amazing for writing documentation. Writers can write inside of Typora and export to pdf (print) and html (web).

Exporting to html even brings in code fence block styles and language color pigments.

Bravo!

It is a great software. Much better than paid options out there. I tested it on Mac and Ubuntu. I wanted Windows version too but was reluctant to install it. Is there a portable version of it? I like to keep it on pendrive.

Edit: Don't mind, I loved it so much and I could stop myself from installing it on my Windows machine too. But I still want the portable version so that I can use it when I don't have admin privileges to install software.

Is that deb source line correct? It's listed in the installation instructions as:

    deb https://typora.io linux/

`apt-get update` barks out the following warning:

    W: Conflicting distribution: https://typora.io linux/ InRelease (expected linux but got )

To suppress the message I ended up changing it to:

    deb https://typora.io/linux ./

VirusTotal scan of the installer, in case anyone is interested: https://www.virustotal.com/en/file/c825f1c56df8802215011f31c...

(1/56 detection ratio and it looks like a false positive)

Some virus scanners have gone full retard and flag all executables they haven't seen before.

Hurm -- I just had Avira and Windows Defender flag it as unsafe. They both said they detected Adware/Filefinder.IL

Is that a common missed signature? Does it have a common pattern?

No idea, to be honest. I'm not really using Windows actively any more, but complaints about heuristics detections crop up all the time.

EDIT: I've just uploaded a test electron binary I made myself to see whether it triggers on all of them. 0 detections for mine, but mine are always digitally signed. I'm not sure whether and how that affects heuristics, but theoretically it should.

Isn't that called vim (or insert your actual editor of choice)?

Markdown is meant to be readable while editing, I actually find having the rendered edition on top of your edition really confusing, when you can just open the .md file in your editor while having your preview outside of it updated after each save.

It's hard to stop being used to the folder-tree in LightPaper, makes it much simpler to organise MD files.

What’s missing in most of these markdown editors (including this one), is the ability to copy the formatted document as clean rich text, for pasting into email and other apps.

For example, a simple document with a list gives you this very clean HTML if you “copy code”:

  <p>Here is an email with a bunch of lists:</p>
  <ul><li>
  <p>Item one</p>
  </li>
  <li>
  <p>Item two</p>
  <ul><li>
  Item three</li>
  </ul>
  </li>
  </ul>

But if you copy the rich text and paste into a contenteditable field, you get this (ugh):

    <div><p cid="c1" mdtype="paragraph" style="box-sizing: border-box; -webkit-margin-before: 1rem; -webkit-margin-after: 1rem; margin: 30px 0px 0.8em; width: inherit; position: relative; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; font-size: 16px; white-space: pre-wrap; text-size-adjust: auto; background-color: rgb(255, 255, 255);"><span class="md-line md-end-block md-focus" cid="c6" mdtype="line" style="box-sizing: border-box; display: block;"><span md-inline="plain" class="md-expand" style="box-sizing: border-box;">Here is an email with a bunch of lists:</span></span></p><ul class="ul-list" cid="c23" mdtype="list" data-mark="-" style="box-sizing: border-box; margin: 0.8em 0px; padding-left: 30px; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; font-size: 16px; white-space: pre-wrap; text-size-adjust: auto; background-color: rgb(255, 255, 255);"><li cid="c24" mdtype="list_item" style="box-sizing: border-box; margin: 0px; position: relative;"><p cid="c25" mdtype="paragraph" style="box-sizing: border-box; -webkit-margin-before: 1rem; -webkit-margin-after: 1rem; margin: 0.5rem 0px; width: inherit; position: relative;"><span class="md-line md-end-block" cid="c26" mdtype="line" style="box-sizing: border-box; display: block;"><span md-inline="plain" style="box-sizing: border-box;">Item one</span></span></p></li><li cid="c33" mdtype="list_item" style="box-sizing: border-box; margin: 0px; position: relative;"><p cid="c32" mdtype="paragraph" style="box-sizing: border-box; -webkit-margin-before: 1rem; -webkit-margin-after: 1rem; margin: 0.5rem 0px; width: inherit; position: relative;"><span class="md-line md-end-block" cid="c27" mdtype="line" style="box-sizing: border-box; display: block;"><span md-inline="plain" style="box-sizing: border-box;">Item two</span></span></p><ul class="ul-list" cid="c41" mdtype="list" data-mark="-" style="box-sizing: border-box; margin: 0px; padding-left: 30px;"><li cid="c40" mdtype="list_item" class="" style="box-sizing: border-box; margin: 0px; position: relative;"><p cid="c39" mdtype="paragraph" style="box-sizing: border-box; -webkit-margin-before: 1rem; -webkit-margin-after: 1rem; margin: 0.5rem 0px; width: inherit; position: relative;"><span class="md-line md-end-block" cid="c34" mdtype="line" style="box-sizing: border-box; display: block;"><span md-inline="plain" class="" style="box-sizing: border-box;">Item three</span></span></p></li><li cid="c40" mdtype="list_item" class="" style="box-sizing: border-box; margin: 0px; position: relative;"><div><span md-inline="plain" class="" style="box-sizing: border-box;"><br></span></div></li></ul></li></ul><p cid="c120" mdtype="paragraph" class="unholdable" style="box-sizing: border-box; -webkit-margin-before: 1rem; -webkit-margin-after: 1rem; margin: 0.8em 0px; width: inherit; position: relative; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; font-size: 16px; white-space: pre-wrap; text-size-adjust: auto; background-color: rgb(255, 255, 255);"></p></div>

Super sweet! Any chance for vim and not hiding the syntax in the styled view? With that I'd switch in a heartbeat.

Also nice to have: optionally show invisible characters. Than the headline margins and doubled spaces become easier to digest.

I'll forgive the application size, because I like it. I hope there are plans to add tabs, because the current approach is a bit clunky, you can switch between open windows with Ctrl+Tab but the windows are independent.

This looks like a WYSIWYM (what you see is what you mean) editor similar to LyX.

This is pretty awesome. My initial thought was that we really don't need another Markdown editor, these are becoming like ToDo lists.

However, it looks awesome, so far it seems to work really well. Support for unicode is great.

I gave Typora a test drive with Readme.MD from Github. The rendering is considerably different, too early to use it.

IntelliJ IDEA MD support is still the best tool IMHO.

Cool app! Glad it's for Windows!

Maybe it's just me though, but I think a smooth transition when the text restructures would make it a lot less jarring.

used various markdown editor these years, I now settle down on vscode for editing and if I need export to PDF I use remarkable which does the job well including various utf-8 fonts.

tried typora quickly, it looks nice, however it can't handle export-to-pdf with some asia fonts in it for me, hope that can be improved.

it's fair to say pandoc can't do utf-8 fonts for PDF reliably either.

Makes sense, Typora uses Pandoc under the covers for it's import/export.

I use vscode for my markdown editing also, but the lack of help with tables and other formatting hurt along with the lack of a offline spellchecker makes vscode a bit painful.

it is weird how you could ignore new startups, then use their products later this is not just an app i like, i actually was going to build this, but when i saw it, i downloaded, tried it, then forget about it don't be disappointing if small people are using it at the beginning, just keep improving it

I have been using MacDown for a while now, which again was a replacement for Mou. But this looks even better.

Is there an AUR or an arch package for this?

not bad start up time consider it's using Electron! Love it so far.

they have done/got a lot of things right.

This is beautiful

> * Free during beta.

Ok, bye.

"A truly minimal markdown editor"

Is less-minimal than nano.

What would that look like? Just nano, but removing the few shortcuts except key entry & save.

Just curious if a WYSIWYG is planned for this. With all the possible languages one can learn, learning one for documentation alone seems like cognitive overload, especially if an application can do it for you

This already is "what you see is what you get" -- are you asking about some kind of buttons for hints to insert the markup for a certain type?

No it's not. You have to type in actual Markdown semantics for the rendering to occur.

You don't write XML when you write in MS word, do you?

The demo shows at least a shortcut key for bold text, I'm guessing there are more.

You do not have to type the markdown. You can press Ctrl+B and bold text. You can right click and insert a Table and fill it in as WYSIWYG.

You can always type markdown but you don't have to.

Pressing Ctrl + / will toggle the whole doc to pure markdown so you can tweak for a second and then flip back to WYSIWYG.

The only draw of markdown is that it's just plain text. If the overhead of learning it doesn't appeal to you then I think a standard WYSIWYG word processor would be a better choice.

I don't see how WYSIWYG conflicts with markdowns version controllability, which is it's real advantage over something like MS word. FYI, markdown has WYSIWYG editors already, and this is one of them. This one relies on keyboard shortcuts versus clickable hints, which MS word offers, making it appealing to a non programmer

Crashes for me on OSX 10.9.5:

    Assertion failed: (tokenCount < maxCountIncludingZeroTerminator - 1), function CUIRenditionKeySetValueForAttribute, file /SourceCache/CoreUI/CoreUI-231.1/CoreTheme/ThemeStorage/CUIThemeRendition.m, line 136.

Reply on news.ycombinator.com