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.
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.
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…)
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 | 13 hours ago
Even as a multi-decade vim veteran this made me properly laugh
chrismorgan | 17 hours 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 | 3 hours ago
Kinda off topic bit it seems like you might know. I assume it's not possible to have more than one?
wrs | 13 hours 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 | 7 hours ago
The performance of GitHub’s code view is also quite poor as the file size gets larger. This architecture might explain why!
jaredkrinke | 14 hours 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 | 13 hours 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 | 9 hours 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 | 14 hours 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 | 14 hours 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 | 12 hours 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 | 6 hours ago
The editor built into EndBASIC qualifies, I think!
fedemp | 15 hours 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 | 13 hours 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 | 13 hours ago
TIL. Thanks a lot.
Unfortunately my anecdote is from 2024, so it was not an option.
artemisSystem | 15 hours 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 | 13 hours 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…)
abareplace | 15 hours 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
cosarara | 6 hours 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.
kghose | 5 hours ago
Editors, compilers, programming languages cryptographic libraries. Like moths to a flame these software types.