One severe limitation with Custom Highlights (::highlight(…)) is that you’re very limited in what you can style: simplifying slightly, it’s just color, background-color, text-decoration and text-shadow. Bold, italic? Nope. Making invisible characters faintly visible (e.g. · for Space and ⇥ for Tab) or drawing faint lines for indentation levels? Nope.
I was trying to change the code font on GitHub with a user script a while back, so I dropped into the inspector. As I imperfectly recall, it’s a textarea (presumably for selection, copy/paste, accessibility) with the same text rendered again on top of it by a div soup for formatting. So when I changed the font in the obvious place, selection no longer aligned with the text. At that point I ran away in fear.
GitHub's browser editor has used CodeMirror for at least fifteen years, and that never worked this way. Or maybe they serve different editors in some situations, I'm not sure.
I’ve been toying with creating an editor that supports terminal, GUI, and web.
Does an editor like that already exist? The closest I’ve seen usually involved xterm.js for the browser, but I was hoping for something native everywhere. And yes, I realize this sounds a bit crazy.
NeoVim uses a client–server model more complete than Vim’s, with a terminal client and multiple GUI clients. No idea if anyone’s made a web DOM client, but without looking I’d expect to find at least a couple of experimental ones. Though it might need some kind of proxy, presuming the client–server protocol isn’t over HTTP (dunno, I’ve stuck with Vim).
Firenvim's first renderer was 100% HTML DOM, but I couldn't make it performant enough for larger screen sizes (the naive approach I used, which matched Neovim's UI updates model, caused too many CSS classes/rules to be created), so I migrated it to a canvas.
There's xi-editor, which utilizes a client-server model and has both TUI and GUI frontends (see the list here). No web one unfortunately (only Electron), and the entire project has been dead for years, but I think it's a very interesting approach and worth exploring further.
I’m using neovim and Firefox’ firenvim extension lets me select a textarea, press a hotkey, and get an inline neovim window (using my neovim extensions etc). It is a bit rough around the edges but beats editing within a textarea.
The Lem editor supports terminal, SDL2 and a webview! (it also had an Electron interface) https://lem-project.github.io/ (the SDL2 layer is discontinued by the maintainer, but still in the source tree)
Another drawback with contenteditable is that it does not support native validation. Recently an employer asked me to create a form with inline fields that would grow according to its placeholder or its content. My first approach was contenteditable, even with a hidden input synced to I could send the data when submitting, but as expected, I could not set one of these fake fields as required and focus automatically when trying to submit.
I wonder how native apps handle accessibility like this. Are there APIs to hook into? If i made an electron app and wanted to render my text area in a canvas, could i hook it up to platform-specific accessibility/text APIs to create a just as accessible experience?
Toolkits like Qt and GTK and browsers like Firefox and Chromium all implement each platform’s native APIs; but those implementations are all fairly tightly woven in. More recently, AccessKit has arisen as the tool of choice for adding cross-platform accessibility, written in Rust. All pure-Rust GUI toolkits that I know of that have any kind of accessibility support use it. Even GTK has recently been switching over to it.
If you’re ever interested in knowing how to integrate with or reimplement as perfectly as possible native functionality, Firefox has been the gold standard for many years (with very fine nuance, generally down to pixel perfection and precise interactions, except for things like rendering high-DPI checkboxes better than Windows itself…)
gtk hasnt been switching over !
it added accesskit to be more accessible on windows and mac, while on freedesktop it still uses its own atspi implementation
The canvas examples have a very weird bug on my firefox on linux, where the text typed will appear exactly on the line above where the cursor shows up. That is, the real cursor is invisible and on the line above the visible cursor.
igorclark | 21 days ago
Even as a multi-decade vim veteran this made me properly laugh
chrismorgan | 21 days ago
One severe limitation with Custom Highlights (
::highlight(…)) is that you’re very limited in what you can style: simplifying slightly, it’s justcolor,background-color,text-decorationandtext-shadow. Bold, italic? Nope. Making invisible characters faintly visible (e.g. · for Space and ⇥ for Tab) or drawing faint lines for indentation levels? Nope.landon | 21 days ago
Kinda off topic bit it seems like you might know. I assume it's not possible to have more than one?
wrs | 21 days ago
I was trying to change the code font on GitHub with a user script a while back, so I dropped into the inspector. As I imperfectly recall, it’s a textarea (presumably for selection, copy/paste, accessibility) with the same text rendered again on top of it by a div soup for formatting. So when I changed the font in the obvious place, selection no longer aligned with the text. At that point I ran away in fear.
snazz | 21 days ago
The performance of GitHub’s code view is also quite poor as the file size gets larger. This architecture might explain why!
marijn | 20 days ago
GitHub's browser editor has used CodeMirror for at least fifteen years, and that never worked this way. Or maybe they serve different editors in some situations, I'm not sure.
jaredkrinke | 21 days ago
I’ve been toying with creating an editor that supports terminal, GUI, and web.
Does an editor like that already exist? The closest I’ve seen usually involved xterm.js for the browser, but I was hoping for something native everywhere. And yes, I realize this sounds a bit crazy.
chrismorgan | 21 days ago
NeoVim uses a client–server model more complete than Vim’s, with a terminal client and multiple GUI clients. No idea if anyone’s made a web DOM client, but without looking I’d expect to find at least a couple of experimental ones. Though it might need some kind of proxy, presuming the client–server protocol isn’t over HTTP (dunno, I’ve stuck with Vim).
glacambre | 21 days ago
Firenvim's first renderer was 100% HTML DOM, but I couldn't make it performant enough for larger screen sizes (the naive approach I used, which matched Neovim's UI updates model, caused too many CSS classes/rules to be created), so I migrated it to a canvas.
sny | 21 days ago
There's xi-editor, which utilizes a client-server model and has both TUI and GUI frontends (see the list here). No web one unfortunately (only Electron), and the entire project has been dead for years, but I think it's a very interesting approach and worth exploring further.
dkl | 21 days ago
According to their latest blog post from four years ago, the xi project is discontinued: https://xi-editor.io/2022/12/09/status-update.html
The successor project doesn't appear to target the web platform: https://lap.dev/lapce/
iamnearlythere | 21 days ago
I’m using neovim and Firefox’ firenvim extension lets me select a textarea, press a hotkey, and get an inline neovim window (using my neovim extensions etc). It is a bit rough around the edges but beats editing within a textarea.
jmmv | 21 days ago
The editor built into EndBASIC qualifies, I think!
vindarel | 20 days ago
The Lem editor supports terminal, SDL2 and a webview! (it also had an Electron interface) https://lem-project.github.io/ (the SDL2 layer is discontinued by the maintainer, but still in the source tree)
fedemp | 21 days ago
Another drawback with
contenteditableis that it does not support native validation. Recently an employer asked me to create a form with inline fields that would grow according to its placeholder or its content. My first approach wascontenteditable, even with a hidden input synced to I could send the data when submitting, but as expected, I could not set one of these fake fields asrequiredand focus automatically when trying to submit.Johz | 21 days ago
Not related to your point, but this might be possible with the
field-sizingproperty, but I don't know how widely supported that is.fedemp | 21 days ago
TIL. Thanks a lot.
Unfortunately my anecdote is from 2024, so it was not an option.
artemisSystem | 21 days ago
I wonder how native apps handle accessibility like this. Are there APIs to hook into? If i made an electron app and wanted to render my text area in a canvas, could i hook it up to platform-specific accessibility/text APIs to create a just as accessible experience?
chrismorgan | 21 days ago
Toolkits like Qt and GTK and browsers like Firefox and Chromium all implement each platform’s native APIs; but those implementations are all fairly tightly woven in. More recently, AccessKit has arisen as the tool of choice for adding cross-platform accessibility, written in Rust. All pure-Rust GUI toolkits that I know of that have any kind of accessibility support use it. Even GTK has recently been switching over to it.
If you’re ever interested in knowing how to integrate with or reimplement as perfectly as possible native functionality, Firefox has been the gold standard for many years (with very fine nuance, generally down to pixel perfection and precise interactions, except for things like rendering high-DPI checkboxes better than Windows itself…)
two | 20 days ago
gtk hasnt been switching over ! it added accesskit to be more accessible on windows and mac, while on freedesktop it still uses its own atspi implementation
abareplace | 21 days ago
Yes, there are APIs. For example, for Windows custom controls (like editors with syntax highlight): https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-supportdocumentcontroltype
kghose | 21 days ago
Editors, compilers, programming languages cryptographic libraries. Like moths to a flame these software types.
cosarara | 21 days ago
The canvas examples have a very weird bug on my firefox on linux, where the text typed will appear exactly on the line above where the cursor shows up. That is, the real cursor is invisible and on the line above the visible cursor.
Exagone313 | 20 days ago
I have it too. In fact, line 1 is not displayed but when clicking and writing it acts like it's rendered correctly.