My favorite model for editing markdown is the one that usecanvas.com and FoldingText (an OSX app) use.

They present the document as WYSIWYG with markdown hidden, but unhide any markdown surrounding or directly adjacent to the cursor. (So the markup from an italic or link span are only visible if you are adjacent to or within the span.)

It's a nice balance between looking pretty and letting me edit markdown directly. I'd love to have an open source editor library that acts like this.

The ability to toggle between markdown syntax and HTML on a per-paragraph basis is an awesome feature! I often prefer the HTML/wysiwyg version but have to occasionally insert something complex which is trivial in markdown. This hits the sweetspot!

It doesn't let you use Markdown by default as a seamless input method like Typora[1]. This editor seems much less productive as you are forced to use your mouse to click on GUI elements.

[1]: https://www.typora.io/

It does not force you to use mouse click on GUI elements. You can use `⌘`+`/` (or `Alt`+`/` on Windows) to switch between WYSIWYG/Markdown modes. Actually it's the preferred way unless you are on mobile devices.

The default mode is WYSIWYG since Markdown syntax frustrates people who don't know Markdown well.

Thanks for mentioning Typora! It's an interesting implementation. I've thought about that approach (in-place real-time preview as you type Markdown text) before, but inside a browser, it's too cumbersome to fight against the inconsistent contenteditable behavior.

Fun fact: there's no "/" key on the German keyboard layout (and possibly others too): to type "/" you need to press Shift + 7.

Wow, that's fun. No wonder few applications use "/" for hotkey combination. Maybe I should use a different key, say, ".".

Yeah, European keyboard layouts are annoying like that. Too bad that it seems unlikely that they would ever change even if there is some talk in France that they want to reform their keyboard: http://arstechnica.com/tech-policy/2016/01/france-says-azert...

There was a project in Finland to reform keyboard layout ("Kotoistus"), only thing they managed to do is to add more dead-key accents and make the keyboard even more annoying to technical users. In all their great wisdom they decided to add non-breaking space character to altgr-spacebar key combination. In isolation that might seem like a good idea, but when also | character required the use of altgr-modifier it was a mess: working with the command line, you tend to have stuff like ... | grep foo. Soon enough there were plenty of users wondering why bash complains that grep is not found: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/218637

Personally, I have abandoned national keyboard layout and adapted US layout instead. Makes both programming and general use much more comfortable. Its amazing how much less I need to use modifier keys now, especially the painful altgr.

The French project would be even worse for us French coders.

Symbols used for code would be hidden behind several layers like altgr combinations. While, imo, archaic symbols (ÇÀÉÈàçê, etc) would be on the first layer.

I'm planning on doing the same as parent, using the US layout, but I can't change my keyboard at work, and although I can type in qwerty, I don't know all the layers like I do azerty, so I can't just type without looking.

You can't change your keyboard at work? That's odd... Where do you work?

Large org, windows, non admin rights. Don't have the rights to plug non approved usb devices.

I can't even use another text editor than the one I have. All those 'vim vs emacs' war-jokes make me laugh. What I wouldn't give to use vim...

I can change the software layout, but as I said, I don't know enough the sublayers of the qwerty layout to be able to type without looking.

I've done the same, to get rid of having 3 characters on the number keys and get access to all the hotkeys.

While also not having keyboard layout change, when SSHing to a server and not being able to make a slash

Many European keyboard layouts require Shift + a number for special characters, so really many hotkeys don't work properly for a lot of software

e.g. / [ ] requires shift key and a number on most.

Ditto Finnish, which is why I hate typing on my wife's keyboard!

"(If you post any article by 8/31, the membership will be extended to the end of 2016; then we’ll see how things go and decide what to do next.)"

aren't these rather crazy terms for a text editor ?

Those terms are for the site, not for the text editor. :-) I might open source the editor when I have time.

Any chance it is or will be open sourced?

Not yet. I might do that later, but it requires some cleanup work.

The code has three parts: Markdown to HTML text, HTML DOM to Markdown, and the editor. The total size is about 30KB uncompressed (27KB JS + 3KB CSS). It didn't use any icon font or images.

I must admit that the way Jupyther/ipython notebooks do markdown is my favorite.

It has all the markup showing, and italize, boldens and changes size of text according to the tags, as well as color coding.

Does it use a "standard" like CommonMark or GFM?

Yes it follows CommonMark, but is stricter for safety consideration (e.g. does not allow scripts).

Nice ! Thanks for the answer.

Does this use CommonMark standard?

Yes, see my question and the answer of the poster below.

Any Github page?

it's pretty basic, I made a more extended one https://caub.github.io/cms/wysi/ markdown isn't really helpful there, since anyway you're just using execCommand

Yes, its HTML editing is pretty basic. I did not intend to make a full-blown HTML editor. There are already many ones.

My goal is to make Markdown and HTML editors working together. I want to support Markdown because it's very productive for long-form article writing.