
Show HN: Slate-md-editor – A markdown editor that allows live editing - chilijung
https://github.com/Canner/slate-md-editor
======
oneeyedpigeon
IMO, the markdown editors that format the text you're editing, but still
retain the markdown, are the very best. They're a good compromise between
readability and functionality. Editors like this (and typora) that obscure the
markdown tend to make it more awkward to change a heading level, for example.

~~~
enobrev
I used to agree with this, but since I started using Dropbox Paper as my
primary editor, I've changed my mind. I don't need to see the markup if the
editor / formatting works consistently.

The different header sizes are immediately obvious without trying to find how
many #'s there are. Monospace words and sections are immediately apparent
without trying to figure out if i used backticks or apostrophes. And I don't
want to "Preview", even if it's a live Preview. I want to see my fully
formatted document as I type it without switching context.

On that note, one thing I wish _all_ markdown editors would pick up, and have
only seen on StackOverflow, is the "Reference Style" links, where you can
denote a link using something like [1], and then list the url below the text.
I have never once, ever, needed to know and immediately see a full url while
reading or editing text. Inline urls actively make editing and reviewing more
difficult.

This is hidden by Dropbox Paper with an actual link as expected, but their
export still has inline urls, which is standard, of course, but I don't agree
with the standard.

~~~
lstamour
> ... But their export still has inline urls, which is standard, of course,
> but I don't agree with the standard.

Just to clarify, inline urls are one of the two standard [Markdown link
styles]([https://daringfireball.net/projects/markdown/syntax#link](https://daringfireball.net/projects/markdown/syntax#link)).

The other is [reference-style][ref].

[ref]:
[https://daringfireball.net/projects/markdown/syntax#link](https://daringfireball.net/projects/markdown/syntax#link)

~~~
enobrev
Thank you, I hadn't realized that was actually part of the spec. I also hadn't
realized how long it had been since I actually read that document.

------
tommoor
When a project appears on HN that's identical to one you're working on… always
a sad moment.

[https://github.com/outline/rich-markdown-
editor](https://github.com/outline/rich-markdown-editor)

Anyway, If you're interested in an open source team wiki built on a very
similar editor then check out the underling project,
[https://github.com/outline/outline](https://github.com/outline/outline)

~~~
z3t4
It means free early feedback. For example I'm working on a JavaScript based
editor like Atom and vscode, and when I announce it will be very fast and it
will be possible to edit GB sized files without any lag. And it will be very
thin, less then 10 MB in size. And use less then 100 MB of memory. If it
wasn't for the other similar projects I would have no idea about these
requirements.

~~~
stephenr
I don’t want to sound like a jerk, but you didn’t know people like things to
be fast and memory efficient _before_ the dumpster fire collection of web view
“code editors” became popular?

~~~
z3t4
I used to worry too back when I only had a few MB. But now I have several GB's
of memory on my dev machine. Also I have not heard people complain about
Ecipse et-al, but when it comes to the web and JavaScript it has to be fast,
or it will be "slow because of JavaScript".

~~~
stephenr
I have 16GB of memory, and I use a java IDE. It uses _more_ memory than the
javascript toy editors do, but it does _so much more_.

If you just want a text editor, there are dozens of native ones for each
platform that don’t require java or javascript and are fast.

It’s when you want stuff like advanced code intel, refactoring, etc that the
likes of JetBrains products make the memory usage a good trade off.

Using a boat load of ram to render a text file slowly with no more features
than textmate or kedit or what have you “because electron” is fucking stupid.

------
niark
If you’re interested in customizing a web-based (rich) text-editor, I can’t
recommend enough the underlying library, SlateJS
([http://slatejs.org](http://slatejs.org)).

I’ve been relying extensively on it for a quite big project, it’s been a
pleasure to use. Especially if you need to change the editor’s content
programmatically.

~~~
humblebee
SlateJS is a really neat way to handle rich text editing. I worked shortly on
a project to build a rich email client with SlateJS being the underlying
library to power the editor. This introduced some interesting issues though
around finding the correct way to serialize and deserialize the html due the
way that slates core plugins normalize the slate state when working with the
different node types (block, inline, mark, text).

The main issue is how to properly associated each html element to a node type,
and fit within the core plugin normalization. This is difficult for having to
deal with arbitrary html coming from all the different kinds of email client
that choose to represent the html structure in their own unique way. However,
this is also where SlateJS shines I believe, as you can just normalize all the
different html formats into a single representation.

strong, b, font[style="font-weight:*"], etc => Mark Bold

The library has probably changed quite a bit (last I used it was v0.21), so I
don't know if my issues are even there anymore, or have changed in some way
since.

Overall though, SlateJS is a really neat project, and really fairly simple,
and allows for some awesome things to happen in text editors that previous I
would believe to be fairly complicated. This is all thanks to the fact that
nodes in the slate state can be rendered as rich ReactJS components.

A simple example of this for our use cases was around using template variables
in an html email template. I never got around to actually doing this bit, but
a variable could be it's own unique node type in the slate state, and allow us
to inject a special react component that would make working with the variables
much nicer for our users. In the production editor at the time, these
variables were just handle bars `{{ first_name }}`, which a lot of customers
accidentally would mess up as they had to write out the syntax.

With SlateJS the vision was to simply render a Variable component that would
serialize back down into handle bars, or later down the road take the json
serialization of the slate state and render that into our own html for sending
out.

I really like the patterns SlateJS uses, and I'm excited for any future
projects that will allow me to work with it again.

------
kamac
It's working as I'd expect it to, which is good. The only problem I have with
it is how it slows down when there's much markdown.

For casual editing though, I still prefer working with a raw markdown file
with a live preview. Simply because I feel like I have full control over
styling. I can remove bold from text without removing the text itself.

~~~
chilijung
The reason we are developing this markdown live editor is that companies have
some non-tech editors, for them raw markdown is hard for them to learn, write
without real-time feedback.

~~~
thanatropism
It'd be interesting to learn more about what exactly these non-tech editors
(that are somehow writing for the web on computing machines) find difficult
about Markdown.

Markdown was designed to be really, really, really easy to write. But it was
designed by techies based on their own experience mostly. Maybe there's a
better, simpler MarkPopular that can be used by a wider user base.

~~~
always_good
Two things that tripped up my users (and sometimes me) and made a live-preview
essential were:

\- Links and images. ![]() and []() are something you'll see people
consistently reverse.

\- Nesting markdown in a list, like images and codeblocks. And forgetting that
two newlines will end the list which can create an unobvious result in the
live preview.

Markdown is easy to write (unlike BBCode) but not always simple to remember,
format, or reason about with its strict whitespace rules (unlike BBCode).

~~~
repsilat
_> []() are something you'll see people consistently reverse._

Yeah, I've seen this. To help people remember (not ideal, but useful) is the
phrase "Robot brackets for human text, human brackets for robot text."

No idea why it helps, you'd expect the reverse to be equally memorable, but it
seems to stick with people.

~~~
always_good
Heh, and then one still accidentally writes !()[] or ()[].

The other nuisance for my users was that the [] text is optional (and
relatively worthless from user POV) in ![]() but not []().

I wonder if `!<url>` for images would've been nice alongside `<url>`.

Reddit + the Reddit Enhancement Suite browse plugin have a decent middleground
where all urls are autolinked but image urls have additional expand/collapse
UI.

~~~
kqr
> the other nuisance for my users was that the [] text is optional (and
> relatively worthless from user POV) in ![]() but not []().

Is it not converted to an alt attribute in the rendered HTML?

------
petepete
Looks decent but some odd things happen.

I don't appear to be able to put more than one formatted section in a
paragraph. The first one works and the second doesn't.

Here's an example with two paragraphs, firstly with bold followed by italic
and second vice versa.

[https://i.imgur.com/QKEz7qM.png](https://i.imgur.com/QKEz7qM.png)

Edit. Also, it appears to add unintended spaces around those formatted words
(see `<em> dog</em>`). And I wish HN supported inline code snippets.

~~~
entropie
Odd. Just tried it and it works fine for me.

~~~
petepete
Strange. I'm on Chrome 65 on Mac if that makes any difference.

------
williamstein
I think ProseMirror potentially solves a similar problem, but is more
efficient:
[https://prosemirror.net/examples/markdown/](https://prosemirror.net/examples/markdown/)
(then click the WYSIWYM radio button). ProseMirror's API became stable a few
months ago; I recently read straight through the documentation and was very,
very impressed (I'm a huge fan of the author marijnh's contributions to open
source, and want to integrate ProseMirror into CoCalc and Jupyter notebooks
soon). ProseMirror is of course very low level though...

------
kqr
I'd really, strongly, very much like this for the Org file format.

------
sharpercoder
I hope to see a pluggable markdown editor sometime. Pluggable in the sense
that the syntax (lexer & parser) are highly configurable and can cater to the
needs of the domain. Because in effect most websites, documents, et cetera 1)
use a certain flavor of markdown and 2) have extensions.

It would be nice to be able to configure a certain syntax and then have the
editor be aware of that syntax. Most editors out there currently only work
with a fixed syntax or a fixed set of syntaxes.

------
mbid
YAME, Yet Another Markdown Editor.

~~~
I_complete_me
NAME, Not ANOTHER Markdown Editor?

------
sachleen
This sort of editor makes it impossible to edit text. Say I want to change a
link or image.. I have to delete it and insert it again. I prefer editors that
show a side by side of markdown and rendered text so I can type/edit markdown
but also see the output. I think that's a better compromise than replacing the
markdown with live text.

------
ergo14
Why people stopped doing solutions that are universal? Does everything need to
have react as as dependency is now?

------
ajkjk
"A markdown editor, that allows you to edit live."

I see this exact grammatical tick, adding a comma where one shouldn't be after
a noun clause, all the time. Maybe it's native speakers of some other specific
language that tend to do it? Which one?

~~~
benschulz
I—a native German speaker—suffer the same tick. Therefore my guess would be
German.

Sentences like the one you quoted have a similar structure as those
deconstructed in ReadsLikeGerman[1]. The "that" feels like the equivalent of
"der"/"die"/"das" and I have the urge to place a comma in front of it.

[1]:
[http://wiki.c2.com/?ReadsLikeGerman](http://wiki.c2.com/?ReadsLikeGerman)

edit: rephrased for clarity

~~~
brokenmachine
> I—a native German speaker

It's hilarious that you had a very similar tic in this response, only with a
hyphen instead of the comma... :-)

~~~
ajkjk
But that was a correct emdash! Not quite the same.

In fact "A markdown editor -- that allows you to edit live." would be correct,
though with a slightly different meaning, sorta treating the latter clause as
a surprising bonus, as though you would expect the opposite if you only heard
the words "a markdown editor".

------
stealthcat
It's like typora.io ?

~~~
splike
I love typora, but this is open source which makes it extendable.

------
favadi
I have to click just to see what is "live editing". So far, it works pretty
much like org-mode.

~~~
oneeyedpigeon
Isn't it obvious from the context what "live editing" is? What else could it
be? What term would be preferable?

~~~
brokenmachine
It's obviously not obvious to everyone.

