I view stuff like this kind of like code that fits into a bootloader or whatever. It’s really more of the technical challenge than to actually solve a problem. The result is much better if you just run a script on your hand-coded file to add syntax highlighting as DOM elements. Still, love seeing stuff like this.
So script inside web page is bad, but script inside font is good? That's interesting definition of bloat. I'd prefer ordinary webpage using locally installed fonts with explicit JavaScript snippet to highlight keywords.
I have yet to see a good web based text editor with syntax highlighting. They all mess with the native search functionality of the browser. Because they can't just use a textarea for the edit area. With this approach, it would be possible.
I wonder how usable a Python version of this would be?
I have yet to see a good web based text editor with syntax highlighting.
I slightly expect you to pull a "no true Scotsman" here and suggest it's actually no good because it doesn't really support mobile browsers very well, but Microsoft's Monaco editor that's driven from VS Code is quite good. https://microsoft.github.io/monaco-editor/
It seems to have the same problems all of the web based editors I have seen have. Either they capture ctrl+f and take away the native search experience. Or they have a broken search experience. This one is in the latter category.
When I hit ctrl+f on that page and type "export":
First it says "1 of 4 matches" but nothing is highlighted.
When I hit enter, it says "2 of 4 matches" and again, nothing is highlighted.
When I hit enter again, it says "3 of 4 matches" and the first match is highlighted.
When I hit enter again, it says "4 of 4 matches" and the second match is highlighted.
Contenteditable plus the CSS Custom Highlight API (which highlights ranges instead of elements) might indeed allow for a good solution. But I have not yet seen an editor that does that.
Has anyone tried this with PowerPoint yet? Our org is very PowerPoint centric and always struggle a bit with the workflow for code.
Copy pasting from IntelliJ does give colours but none of the other niceties such as kerning or litigation. Screenshots are nice visually but a pain to maintain.
> It only works where OpenType is supported. Fortunately, that's all major browsers and most modern programs. However, something like PowerPoint doesn't support OpenType.
Yes, ligatures. No idea where “litigations” came from.
I think there is still some kerning going on where the individual letters are placed closer together and the entire word has the same width so more spacing in between words.
> Works in <textarea> and <input>! Syntax highlighting inside <textarea> has been previously impossible, because textareas and inputs can only contain plain text. This is where the interesting
Interesting indeed! This bit feels like a neat bit of hackery to keep in my back pocket for sure.
Well someone else mentioned llama.ttf which is a font that embeds an llm, using Harfbuzz's WASM engine.
So, you could absolutely write a WASM Z80 emulator and embed it in a font. Whether or not you could make it do anything useful, or how strong your grip on reality would remain after? I don't know.
But it wasn't like you were doing anything else on the days between Christmas and New Year, right?
This is a curious sort of hazy modern mirror image of the world of Sinclair computers, that embedded their BASIC parsing in the keyboard driver — that is to say, it essentially wasn't possible to type a syntactically incorrect BASIC program.
I view stuff like this kind of like code that fits into a bootloader or whatever. It’s really more of the technical challenge than to actually solve a problem. The result is much better if you just run a script on your hand-coded file to add syntax highlighting as DOM elements. Still, love seeing stuff like this.
For blogs, I like the site to stay static. This is a neat way to keep it that way. Having your generator do it is better in my opinion though.
So script inside web page is bad, but script inside font is good? That's interesting definition of bloat. I'd prefer ordinary webpage using locally installed fonts with explicit JavaScript snippet to highlight keywords.
Unless I missed it, the OP doesn't quote reducing bloat as a motivation- more just working without javascript.
I took it to be along the lines of an "easier to work with" type motivation, rather than reducing package sizes.
Is it really a script though? IIUC it's more like contextual declaration (e.g. of previous char is X, then use style Y), no?
Remember llama.otf?
llama.ttf
https://fuglede.github.io/llama.ttf
This is interesting.
I have yet to see a good web based text editor with syntax highlighting. They all mess with the native search functionality of the browser. Because they can't just use a textarea for the edit area. With this approach, it would be possible.
I wonder how usable a Python version of this would be?
I have yet to see a good web based text editor with syntax highlighting.
I slightly expect you to pull a "no true Scotsman" here and suggest it's actually no good because it doesn't really support mobile browsers very well, but Microsoft's Monaco editor that's driven from VS Code is quite good. https://microsoft.github.io/monaco-editor/
It seems to have the same problems all of the web based editors I have seen have. Either they capture ctrl+f and take away the native search experience. Or they have a broken search experience. This one is in the latter category.
When I hit ctrl+f on that page and type "export":
First it says "1 of 4 matches" but nothing is highlighted.
When I hit enter, it says "2 of 4 matches" and again, nothing is highlighted.
When I hit enter again, it says "3 of 4 matches" and the first match is highlighted.
When I hit enter again, it says "4 of 4 matches" and the second match is highlighted.
FYI, IDEs and editors too don't use "textarea". Contenteditable essentially makes the web browser work like editor does.
Contenteditable plus the CSS Custom Highlight API (which highlights ranges instead of elements) might indeed allow for a good solution. But I have not yet seen an editor that does that.
Has anyone tried this with PowerPoint yet? Our org is very PowerPoint centric and always struggle a bit with the workflow for code.
Copy pasting from IntelliJ does give colours but none of the other niceties such as kerning or litigation. Screenshots are nice visually but a pain to maintain.
From the article cons section:
> It only works where OpenType is supported. Fortunately, that's all major browsers and most modern programs. However, something like PowerPoint doesn't support OpenType.
Thank you, I missed that third sentence.
*ligatures
Is kerning a thing for monospace fonts?
Yes, ligatures. No idea where “litigations” came from.
I think there is still some kerning going on where the individual letters are placed closer together and the entire word has the same width so more spacing in between words.
Using a variable font with r, g, b axes for each alt would maybe make it possible to change the colors?
> it breaks when your code goes to a newline. there's no way to keep context line to line...
This is a blocker for my applications.
> Works in <textarea> and <input>! Syntax highlighting inside <textarea> has been previously impossible, because textareas and inputs can only contain plain text. This is where the interesting
Interesting indeed! This bit feels like a neat bit of hackery to keep in my back pocket for sure.
Perhaps you could add this technology to Z80 sans, to get syntax highlighted Z80 disassembly.
https://github.com/nevesnunes/z80-sans
And add Z80 emulator as well. Just in case.
Well someone else mentioned llama.ttf which is a font that embeds an llm, using Harfbuzz's WASM engine.
So, you could absolutely write a WASM Z80 emulator and embed it in a font. Whether or not you could make it do anything useful, or how strong your grip on reality would remain after? I don't know.
But it wasn't like you were doing anything else on the days between Christmas and New Year, right?
This is a curious sort of hazy modern mirror image of the world of Sinclair computers, that embedded their BASIC parsing in the keyboard driver — that is to say, it essentially wasn't possible to type a syntactically incorrect BASIC program.