I know that everything looks like a nail if your only tool is a hammer, and it's fun to nail together square wheels out of plywood, but there are actually other tools out there with built-in, compiled, optimized, documented, tested, well maintained, fully compliant JSON parsers.
Performance depends on what toolset you’re using and how large your data set is.
For small JSON documents, like a package.json file, jwalk is around ten times slower on my machine: 0.03 seconds, vs 0.004 seconds for jq.
For larger documents, like the 1.5 MB GitHub API response tree.json [1] in the jwalk corpus, jwalk on mawk takes 0.37 seconds vs jq’s 0.11 seconds, but jwalk uses just 1.18 MB of memory, vs jq’s 5.81 MB.
Other interpreted parsers don’t fare as well: JSON.awk [2], which only runs on gawk, takes 0.8 seconds and 27 MB to parse tree.json; JSON.sh [3] takes 201 (!) seconds and 43 (!) MB, and JSONPath.sh [4] takes 7.4 seconds and uses 1.7 MB.
Try to imagine yourself in the shoes of someone who doesn't know HTML and just wants to write a message or comment with a little emphasis and maybe a bulleted list. That's the majority of our customer base at Basecamp.
Creating an editor for that does sound like a simple task, doesn't it? Except the tools the browser gives you just don't work, as we've experienced first-hand over the years in the form of customer bug reports.
I was involved with the Wysihat project too. What we found is that its approach, like most other editors', is fundamentally broken. We created Trix to solve the problem. https://github.com/basecamp/trix#different-by-design
I think you'll find Trix's toolbar easy to style however you'd like, but if not, it ought to be straightforward to implement your own using the API.
Cool, and great work! I had a small e-mail conversation with Josh (forgot his last name) a couple of years back, I thought he worked on Wysihat alone.
I have seen and tested some RTEs for the web, and I can only imagine how hard it is to come up with a durable solution. So thanks for Trix and good luck!
P.S. Trix also has a 'royal' connotation to me, because it's short for Beatrix in The Netherlands. Beatrix being the former queen.
Sadly, while the Scribe developers correctly identified all the various problems with contenteditable (https://github.com/guardian/scribe/blob/master/BROWSERINCONS...), they chose to solve it like most other editors: by using execCommand, waiting for the browser to make a change, and then attempting to clean it up afterwards.
Trix's thesis is that this approach is fundamentally broken. Instead, Trix updates an internal document model on each input event, then re-renders the editor contents in response.
Trix fully supports file attachments and image attachments, as documented in the readme. It includes an inline caption editor for images.
Trix also supports "content attachments" (currently undocumented) which allow embedding arbitrary HTML as attachments in the document. Basecamp 3 uses this feature to embed @mentions with avatars, and various oEmbed types, in messages and comments.
I want to see those "content attachments" as a live demo!
I'm currently using CKEDITOR in a Rails app and inserting HTML "templates." CKEDITOR renders the HTML and allows the end-user (or content creator) to modify the HTML while it is rendered inside the contenteditable text area.
"Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now."
Incorrect. It is support for an enhancement that rbenv provides.
You often want to invoke an application binstub from another program such as cron, and you want to use the per-project Ruby version specified in the application's root directory. Other version managers require you to spawn a subshell and load the version manager into the shell or otherwise set up the per-project Ruby version environment, then `cd` into the application directory, and finally run the binstub.
rbenv requires an environment set-up step too—set `RBENV_DIR` to the application root—but provides a wrapper that eliminates the need for such gymnastics. When you change a binstub's shebang to `#!/usr/bin/env ruby-local-exec` rbenv automatically searches up the binstub's directory tree to find the right Ruby version.
Thank you for clarifying the exact circumstances, Sam. I don't use rbenv, I was going by discussions on the ticket and in Campfire. I was referring to that difference in the binstub, but maybe should have been more clear that that's a conflict with the enhancement and not the base features of rbenv.
