marijn

I've added a bitcoin address (but didn't integrate it into the automated checkout flow, so you'd have to email me to claim perks).

I've made them a little brighter, hope that helps.

I finally figured out how to apply a functional / unidirectional data flow architecture to the (demanding) case of an editor. And yes, there are plans to integrate this into CodeMirror at some point.

Markdown demo should be fixed now, thanks!

Thanks once more -- that was another build problem.

Yes, it uses contentEditable. There's a write-up from last year at http://marijnhaverbeke.nl/blog/prosemirror.html . Some details have changed (we make more use of DOM diffing and mutation observers than initially hoped), but most of the info there still applies.

Thanks for letting me know! I was failing to include a CSS file—should be better now.

Yes, I have a small patreon at https://www.patreon.com/marijn. Right now I'm also running a crowd-funding for the new edition of my book at https://eloquentjavascript.net/3rd_edition/

That's great to hear! Learning curve is definitely something that's tricky with a library like this (big, modular, with concepts that are unfamiliar to many), so I've tried to compensate with consistency and lots of documentation.

I wrote this. I'll be monitoring this thread and responding to questions here for the next few hours.

I assume NoStarch.com will have them available for pre-order in a month or so.

That is not a perk that's being offered.

Thanks. I found the 'existance' typo. What do you mean by 'is run by'?

I'd add that the assumptions that the specialized data structures (gap buffer and piece table) make are easily violated—someone mentioned a search-replace further down—at which point I can imagine their performance degrading unless special measure, i.e. more complexity, are added.

So yeah, in my editor (CodeMirror) I'm also using a rope/tree style representation [1], because it's pleasantly general and easy to reason about.

[1]: http://marijnhaverbeke.nl/blog/codemirror-line-tree.html

ProseMirror was started 2 years ago, initially only targeted evergreen browser, and has recently grudgingly added support for IE11 because customers asked for it. But yeah, I guess for some parts of some of the older projects this may apply.

... more than a little, even. I'll talk to the designer of the logo.

What do you mean by tooltips?

There's a solution in the works for the latter problem.

And those evergreen browsers are still doing terrible things when it comes to contentEditable, and they don't really have a lot of choice, because it's an underspecified poorly conceptualized idea that really doesn't leave them much room to things right. There's some work happening on the W3C editing taskforce to improve the concepts involved, but that's also moving at a glacial pace, and having to struggle with browser vendors at every steps.

So again, don't suggest we (editor implementors) are clueless or behind the times. We happen to have spent quite a bit of time on this stuff. We know it.

Thanks for pointing that out. CSS is hard. Should be fixed now.

Good point -- I had some CSS attached to H1 nodes that accidentally also matched H1s in the editor. Should be fixed now.

Nonsense, I've written a much smaller one: `function tinyEditor(element) { element.contentEditable = true }`

That, plus a few crude buttons, is all this does. As several other comments point out, there's good reasons why real WYSIWYG packages are bigger—the user experience of working with a plain contentEditable element is still terrible, the output HTML still a complete mess. If you don't care much about that, you don't need an editor component, since setting an attribute and wiring up some buttons to call `execCommand` is easy enough to do from scratch.

Disclaimer: I work on one of those 'bloated' editors, http://prosemirror.net , and find it a little annoying when someone implies their crude afternoon hack is somehow equivalent and we're crazy for putting in all that effort.

There's a long-standing tradition of using flagging to suppress unpopular links. Seems like it still works.

> It's nice to look at

I don't think it is -- it's full of the kind of features (complicated condition expressions, long chains of elses, hard-coded numbers) that, when I find myself writing them, suggest that I'm approaching the problem in the wrong way, because previous experiences make me associate that kind of code with lack of generality and corner-case bugs.

Yes. They both just lower the code to ES5 syntax without introducing any incompatible constructs.

That yields, amusingly, a blank page for me right now.

Hahah, you think the other vendors are better?

At least the Epson stuff I've owned is easy to install with Linux and doesn't break after a few months of use (contrary to various Canon and HP devices). If there exists a non-terrible printer manufacturer (in a consumer budget range) do tell me.

Potentially relevant: CodeMirror's BTree representation http://marijnhaverbeke.nl/blog/codemirror-line-tree.html

That's interesting, thanks for sharing.

The project is now at a point where contributions would make sense -- the API is documented, and the design somewhat stable. The area I'd most like help with is finding and resolving bugs -- strange browser behavior (contentEditable is a fountain of strange browser behavior) and issues on mobile. I'm still too busy moving the larger pieces forward to spend a lot of time testing.

What kind of improvements would you want in the docs [1]?

[1]: http://prosemirror.net/docs.html