Comment by marketmecha
1 month ago
Vim-inspired, as in it's minimal and fast, text editor on the web. No modal-editing yet but, once the current natural input mode is decoupled, clients can bring their own modes/controllers via the extension system.
It's meant to be embeddable and hackable, serving as a building block for custom IDEs as opposed to being IDE-like VSCode. I felt the web IDE space was uninspired with apps built around VScode/Monaco effectively being hosted a VSCode instance with a pre-installed extension and config.json. (Aside: perhaps there's a business opportunity for VSCode-as-a-service where client apps simply bring their own config). I'm dogfooding this library in building an algo trading IDE.
Ships 2kb and smoothly handles 50+ million line files. 1 billion lines with the high-capacity extension. Also, it can function as a TUI or terminal on the web because the core implementation concerns efficiently rendering plaintext in a fixed-width grid layout.
this looks very nice.
I see this doesn't use <textarea> or contenteditable, I'm curious how close can it get to native controls or can this replace them? Things like mouse selection and usual hot keys like Cmd+A and maybe other things.
> I see this doesn't use <textarea> or contenteditable
Technically, there is <textarea> but it's strictly for a more seamless interface with copy/paste. The web standard's clipboard API was not satisfactory.
> mouse selection
There was previously mouse selection but that was removed after I rewrote the selection logic. This will be re-introduced as an extension that be can opt into. It's relatively trivial for a mouse but will be harder to be robust with touch events.
One tricky bit will be the UX of scrolling and selecting at the same time, especially on mobile phones.
> usual hot keys like Cmd+A and maybe other things.
The general philosophy is to not assume any native controls, have zero default key handlers and have clients bring their own extension that adds this functionality. Cmd+a in particular would perhaps be something I can add directly in the default keyboard controller.
The underlying API is defining operations from two coordinates. From the current exposed API you can also get the last line, and from there get the last coordinate. This could be a new API I expose. With (0,0) and the last coordinate, the keyboard handler would just call that.
The one limitation is that we have to convert a bunch of lines of string into a giant string into the user's clipboard. This overload the browser's clipboard buffer once we get to a million lines of code.