Any docs for how to use text-buffer standalone, like Monaco, CodeMirror, Ace, and others?

[trusktr]

I'm curious about this. I currently use CodeMirror for some projects:

• <code-mirror> element - a Custom Element wrapper around CodeMirror, without compromising on any features (built-in plugins/themes can be specified by string name via DOM attributes for simple cases, while any plugins/themes can be passed in via the JS props for full control (i.e. via templating systems in React, Svelte, Solid.js, etc) to keep things declarative)
• <live-code> element - an element that uses <code-mirror> to build a live code preview: write HTML on the left, see the live result on the right as you edit the code. Think mini CodePen, embedded anywhere.
• Examples on the Lume docs site are all made with <live-code>: https://docs.lume.io (don't try Safari desktop, try Chrome, I recently started using Safari and noticed it freezes the whole tab for some reason)

I used CodeMirror v6+ because it was built with mobile support from the start, so it works on any phone, using native touch-based text editing controls (f.e. hold finger down to see the OS-native magnifying glass, drag to place the cursor, etc). It's very modern in that sense. Monaco mobile support is essentially none currently.

I'm curious about text-buffer. Maybe it can be renamed to something else (random idea: pulsar-buffer) so that on its own it can live with a name and used independently.

A custom element would be <pulsar-buffer>. Or is that what <atom-text-editor> already is? Maybe the question is about that.

Curious if it can be used standalone, or what it would take to make it standalone.

Also curious how it compares to CodeMirror. Does text-buffer have mobile support? If not, would it be worth migrating to CodeMirror instead, or maybe the ideas can be borrowed for text-buffer?

[savetheclocktower]

A custom element would be <pulsar-buffer>. Or is that what <atom-text-editor> already is? Maybe the question is about that.

That is what atom-text-editor already is, yes. But it was not envisioned to be usable outside of an Electron environment — nor even outside Pulsar.

In short: TextBuffer is abstract and TextEditor is concrete.

TextBuffer itself can be used standalone, but not easily. It depends upon access to Node modules, so it must be used in a Node environment one way or another. In Pulsar that's easy because we still use the (deprecated) Node integration in the renderer process, so TextEditor can be written as a Node module that can also access standard DOM APIs.

Here's what TextBuffer does:

• Manages the data structure of a buffer (implemented by superstring as a Node module with native bindings; a WASM version exists but has not seen much focus)
• Assigns grammars to buffers
• Manages the display layer abstractly (knowing how many characters are in each line, knowing when to hard-wrap/soft-wrap, knowing when to invoke iterators to apply syntax highlighting)
• Tracks undo/redo history
• Tracks markers (arbitrary regions of text) and how they move as a result of edits
• Allows for grouping of markers into layers
• Reads from disk and writes to disk

Meanwhile, the TextEditor component wraps around a TextBuffer and handles anything DOM-specific about the presentation layer:

• Turns abstract syntax highlighting iterators into specific DOM constructs (span elements with class names applied)
• Knows where to place the cursor when you click on a point within the editor
• Translates screen coordinates to buffer coordinates, and vice versa
• Handles keyboard events

So: can TextBuffer be used standalone? Not easily, since it relies on superstring. For it to be truly portable, you'd need a proper WASM implementation of superstring and probably a couple other libraries. Or else you'd have to declare TextBuffer in a Node environment and have it talk to a frontend DOM environment via message-passing.

In theory, you could write a different “frontend” for TextBuffer — a terminal emulator, a canvas element — but I'm not aware of anyone who's tried to do this.

There is one place where TextBuffer comes in handy even though it wasn't specifically designed for this: if all you want to do is syntax-highlight arbitrary text against a grammar, you can skip TextEditor altogether. This technique is used in pulsar-hover, among other places, and is vastly superior to techniques we've used elsewhere for syntax highlighting (like creating a read-only TextEditor and trying to get it to behave as though it's just an ordinary pre rather than an editor).

So it would take a bunch of work to make something that wrapped TextBuffer and delivered a product similar to CodeMirror. That's not on our roadmap, but it would certainly be an interesting thing to pursue, and it might solve some useful problems along the way. (We really do want to have a WASM version of superstring in our back pocket so that we're not painted into the corner of Electron’s Node/browser hybrid environment, but last time @mauricioszabo experimented with it, the performance wasn't good enough.)