Here's a tested version that, given text containing only lower case letters, backslash and double quote, capitalizes the letters between quotes and handles escaping reasonably. (works with NotoSans-Regular.ttf)
@Char = [a-z quotedbl backslash];
@CharQuoted = [A-Z quotesingle slash];
@NonQuoteQuoted = [A-Z slash];
@Escaped = [asterisk dollar];
feature liga {
lookup xa {
sub quotedbl @Char' by @CharQuoted;
sub slash backslash' by dollar;
sub slash quotedbl' by asterisk;
sub [@NonQuoteQuoted asterisk dollar] @Char' by @CharQuoted;
} xa;
} liga;
feature liga {
lookup xb {
sub quotesingle' by quotedbl;
sub slash' by backslash;
sub dollar' by backslash;
sub asterisk' by quotedbl;
} xb;
} liga;
although that would also change "snāke" to "snāk", which is not quite what you asked for.
I don't think there's a way to do many-to-many substitution in general, although it would always be possible if you create intermediate glyphs. I believe Section 5 of http://adobe-type-tools.github.io/afdko/OpenTypeFeatureFileS... gives the full list of substitution types.
(author) The problem is that the opentype "language" doesn't have loops or anything resembling regular expressions, where I could just tell it to sub everything between two characters. So, I could highlight text between quotes, but only up to a certain arbitary limit, so I chose not to implement that at all.
Or did I misunderstand your comment? Care to elaborate on your idea?
I'm not the person you're replying to, but it looks like it's possible to carry around a finite state machine, hence get the power of regular expressions (with caveats). I made an example that should highlight quoted text: https://news.ycombinator.com/item?id=41254638
It doesn't check that there's a closing quote, but it should work for highlighting syntactically valid code (once you fix my mistakes). I don't see a way for a character to affect others arbitrarily far back unless some fancier features like ignoring certain classes can be abused.
(author) Because then you're not adding syntax highlighting to the textarea, but to the div... I've done this before and it's janky, with many edge cases that require extra css fiddling. It's just not great. I would rather use a library like codemirror even in seemingly simple cases like that, but fortunately I don't have to anymore : - )
(Author) Sure, it depends on your requirements, what you want your syntax highlighter to do. I wouldn't use it as my coding font (in its current form at least). But just because a few words inside regular text could be highlighted, doesn't make the code that much less readable — in the context of code snippets on websites.
(Author) For specific keywords, yes, technically you could, but it would require making a separate glyph for each word, which would inflate the file size and require a lot of manual effort for no apparent upside. The substituting logic is as rigid as with calts. Unless you had some other idea how to use ligatures?
You are probably right, but I would like to see some actual benchmarks and tests. Unfortunately I didn't have time to do them myself yet, but I am curious what the difference between this, a basic font, and a highlighter script would be for a very large document.
It's definitely going to be significantly slower as a result of all the contextual lookups.
To get an idea, I repeatedly duplicated the CSS in the "tiny sandbox" until there were nearly 20,000 lines there, and then profiled the operation of changing the font-size by 1px in Firefox. Reflowing the textbox took about 1.6 seconds.
With `font-feature-settings: "calt" off` applied, so that the contextual lookups aren't being run, a font-size change for that same textbox content reflows in about 100 milliseconds.
(I don't have actual timings for the same example in Chrome, but subjectively, with "calt" disabled, the resize is near-instant, whereas with it enabled, it's quite laggy, similar to Firefox.)
In Firefox, 4000 lines of CSS: editing last lines is fast and instant, editing first lines is a bit jumpy refreshing every few edits in 0.2s-1.2s - however undo/redo is quite fast - but not so fast as with last lines, and.. from the first impression, guesses:
-= the highlight is always there, instantly =- (or.. it doesn't a look like a reason for jumpy lines because of redo) - definintly less cycles and memory overhead and I don't see that possible with DOM and JS - the delays could be there only because of inefficient editing operations with no impact of coloring.. and maybe with.. smaller textfragments (or ?) there could be no such delays at all - but simple* coloring coud be always so instant (and easy) ? (yes, I know, so far it may be also limiting and exclusive)
And about the lookup rules: they are extremely simple. You can search for a single character at a time, or search from a group ("class") of characters. AFAIK, that's it. But if anyone knows better, I would be happy to be proven wrong.
Maybe this could also be implemented using variable fonts[0]. This would probably make it easier to configure in non-browser environments (once this is better supported by font selectors etc).
