Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Primrose – A text editor that draws to Canvas (capnmidnight.github.io)
49 points by moron4hire on Jan 4, 2015 | hide | past | web | favorite | 34 comments

You clearly get that licenses matter, but you've released your code under the worst of all possible licenses, namely "contact me for permission."

This is an easy one to solve, it just takes a moment to pick a real license for your project[1]. Real licenses are more than one sentence long because there are real issues that both licensor and licensee need to understand before they can go forward.

[1] http://opensource.org/licenses

If you look at the Github repository, you will see that I have a license file that specifies GPLv3. "Contact me" really only means "I haven't setup a site for you to buy a dual-license for non-FOSS projects yet, because the project isn't done".

awesome, I'd mention GPL3 in your README licensing section - so many projects lack any kind of license file that even when I thought I'd looked for one I missed it and walked away thinking you just had the vaguer statement.

This reminds me a bit about the Mozilla Bespin editor from several years ago. They've since merged with the ACE editor, but before the merge they drew everything on a <canvas>. There's some more information about that here: http://benzilla.galbraiths.org/2009/02/17/bespin-and-canvas/

If you think that Primrose is neat, checkout Daniel Earwicker's carota editor. It's based on a similar idea and has way more features, as well as a license that won't hose your project (MIT):


Pretty sweet demo: http://earwicker.com/carota/ !

Thanks for the plug!

Caveat: Carota does not solve Right-To-Left text or complex scripts, and I'd really appreciate help with that. It's the only blocking issue against me using it in my main work project.

(By a strange coincidence I use the codename Primrose in an unrelated project...)

Nice demo but far from usable as an actual editor IMHO.

Doesn't seem to support a lot of common ways I edit text, like holding shift and using arrow / alt-arrow to select. Selecting and hitting delete. Selecting with the mouse and hitting delete doesn't work.

Does not work on Firefox Developer Edition at all.


"works in Chrome" is just all the further I've gotten so far in a weekend. I can eventually get it to work in Firefox, just need a little more time to build out the features.

Just reporting... sorry if I sounded too harsh. I actually love the idea and appreciate the effort!

No, it wasn't harsh. I'm still learning how to communicate my projects here. Trying to figure out the right level of doneness (somewhere between "tartar" and "shoe leather") before serving it up to the HN masses is its own project.

I've encountered the problems you're trying to solve. First, it needs to handle word wrapping which yours doesn't seem to do. After that, it's i18n text that make this a difficult problem to solve. Specifically, RTL languages and CJK.

Release early, release often--or, we'll cross that bridge if we ever get to it.

Unfortunately, I'm not out to make a tool for everyone in the world. No, I don't have a plan for those issues, but I and at least one other person I know have need for text editing in a WebGL context (specifically, with WebVR work). For that, I need a canvas element that I can make into a texture.

The only previous work towards such a thing I could find was a Kickstarter that failed to deliver (https://www.kickstarter.com/projects/1241383920/open-source-...). The current status is that there is no way for any locale to have even antiquated ASCII text, highlighted, and working with editor controls, in a WebGL context.

Text in WebGL is still really immature.

I've done a bit of tinkering with a variety of modules for word-wrapping, etc. None of them are "fully featured" or 100% stable but I have used them in a couple of production environments.


The WebGL module on top of that:


The main issue I have with most text libraries (like TxtJS) is that they assume 2D canvas, or trivial WebGL applications. The bulk of the text code really just deals with laying out rectangular glyphs; the rendering (whether geometry, bitmaps, SDF, etc) should be separate so the dev can choose the best technique for their app.

An example of SDF / fontpath in action:


I understand. By your problem statement, I thought you were more interested in replacing content editable or a text area. An editor that adds text to canvas with manual line breaking has been done plenty of times before.

It seems to use it's own keyboard layout, not the one set in the operating system/printed on my keyboard.

They all do this, this is the big problem in why we're stuck with crappy text areas and content editable. The JavaScript keyboard API was designed for Americans. It does not know about combining accent keys, IMEs, etc.

There is also this inconsistency that's irritating. I'm typing on a qwertz keyboard and in Primrose, z is z (instead of y). But all 'special' characters are qwerty layout.

Great result for a weekend still :)

(it also hijacks ctrl+f/ctrl+c/… anywhere on the website and just inserts the letter instead of calling the browser function)

All this makes me wonder whether this is the right approach and whether this couldn't be done with a lot less hassle with CSS formatting.

Well, the problem with CSS formatting is that it doesn't composite well with 3D scenes in WebGL contexts. That's the ultimate goal here, to have 3D objects in a VR application with code editor surfaces (for which I have another project running as well).

My code already uses a rudimentary code page system, just because it's impossible to go from DOM keyCodes to the correct text for even US keyboards, so in the long run this should be easily fixable.

This is awesome. The demo works really well in Chrome, actually almost better than native text editing for me.

I am curious, what is the use case where you want a 3d transformed and depth-buffered text editor?

In support of Brian Peiris' RiftSketch, as well as other, similar projects: https://github.com/brianpeiris/RiftSketch/

It was something he and I discussed a few months ago and this was the first chance I had to work on it.

My project CodeChisel3D has a similar goal: http://robert.kra.hn/projects/live-programming-with-three-an...

moron4hire, robertkrahn01 funny for you two to meet here. I have been working on a solution for RiftSketch that is more like Robert's approach, where I use a canvas backed by an actual textarea (Robert's canvas is cleverly backed by an Ace Editor instance). Instead of re-implementing an editor from scratch, the user keyboard inputs are received by the textarea while the canvas and corresponding 3D texture are simply a re-rendered mirror of the textarea's contents and cursor/selection state. That way you can still rely on the usual editor mechanics (cursors, text selection, keyboard shortcuts, etc.).

How do you get the textarea, or any other element, into a canvas?

I don't. The textarea remains hidden (off screen) in the background. It has the user's focus, so when the user types, it's receiving keystrokes as usual. Simultaneously, the render loop simply reads the text and selection state (selectionStart, selectionEnd) from the text area and renders the textarea's text and selection cursor/selection-highlight onto a canvas.

Same approach here. Except that I use the ace editor (http://ace.c9.io/) as the backend. This has the nice advantage that you get full code editing capabilities in 3D.

A more common scenario is non-editable 3D text for UI, HUD, infographics, etc. The core glyph layout, word wrapping and rendering is all the same, just without interaction.

Wow, that's not much code. I'm going to have to study this.

Yes, and it could even stand to be cut down more, which I find exciting.

This is not going to be anything approaching the complexity of something like Vim. Think more like Notepad2. I spent basically the last 20 hours putting together this POC just to see if the rendering was even going to be clean enough to bother going further. And it looks like it is!

Well I've got a weird little project I'm starting that might be about to change direction.

Any plans to support bidirectional text?

Maybe. Trying to keep things simple, to start.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact