Syntax Highlighting and Large File Handling for nvALT

nvALT has been coloring Markdown in the editor for a while now, and the preview just learned how to color code. Both of those are nice. Neither of them was built for a note the size of a short novel, so I drew a line.

Coloring the note you’re writing

With Markdown completions on, the editor paints the syntax from your theme. Headings, emphasis, links, lists, code, ==highlight==, and CriticMarkup all pick up the colors in the .theme file. If a theme never defines CriticMarkup, deletions, insertions, comments, and highlights fall back to red, green, cyan, and yellow.

That coloring is the good kind of fidgety. It makes a normal note easier to scan. It is also a scan of the note, and doing it on every keystroke is how handling a big file gets messy. Under about 300KB, an edit now recolors the lines you actually changed, plus the fenced block or critic span those lines sit in, instead of walking the whole note again.

Files over about 300KB don’t get syntax highlighting anymore. nvUltra does a fine job of syntax highlighting on huge files, and Fletcher deserves all the credit for that, but working with the older text system on nvALT was too inefficient to handle such large texts.

The preview got a highlighter too

Fenced code blocks in the preview run through highlight.js. A Ruby fence looks like Ruby. A bare code block, with no language on it, still gets the generic treatment. Inline `code` is left alone, and a Mermaid diagram stays a diagram.

The default colors are the GitHub light and dark token sets. Both are loaded, and both start turned off. After the page is up, the preview looks at the background behind the code. Transparent backgrounds don’t count. It walks up until it finds a real color, then picks the light palette or the dark one. The cutoff is the same lightness check the rest of the app uses. The code block’s own background stays whatever your preview theme already gave it.

Put your own colors in the theme

If you want the highlighter to match a preview theme, put the classes in that theme’s CSS. Those rules land after the built-in sheets, so anything you define wins.

.hljs {
  color: #e5e9f0;
}
.hljs-keyword,
.hljs-type {
  color: #81a1c1;
}
.hljs-string {
  color: #a3be8c;
}
.hljs-comment {
  color: #7b88a1;
  font-style: italic;
}

Leave them out and you don’t get a random default — the preview still chooses the light or dark GitHub palette from the background. Specify them and it uses yours.

Cool features, expensive notes

Syntax coloring, CriticMarkup, automatic list renumbering, closing a code fence when you hit return, the live word count. I like all of that in a note I can see on a couple of screens. On a huge note, each of them wants to read a lot more text than the character you just typed.

Past about 300KB, highlighting switches off. The theme’s foreground color stays, so a dark theme like Svelte doesn’t drop you into black text on a dark background, including the characters you’re typing. Return inserts a return. It does not walk the file to renumber every list or to decide whether a fence is open. The word count goes blank rather than splitting a megabyte of text into words on every keystroke.

A megabyte is fine. A novel is not.

nvALT is designed for a large pile of small notes with a fast search box in front of them. A title is an index entry. A tag is a shelf. The search field is how you find the sentence, because the sentence has its own note. That is the whole trick. A 200-page document fights it. You can’t search your way to a paragraph you buried under a heading six screens down, and every edit asks the editor to understand structure that runs on for thousands of lines.

Split the long one. One note per meeting, per bug, per quote, per half-baked idea. Searching gets better, and so does editing, because the note you’re in is the note you meant to open.

If you do paste in something enormous, it will no longer choke. I tried a 1MB note. You can scroll it, type in it, and press return at the end. You just don’t get the fancy coloring and the automatic list fiddling while you’re in there. That’s the trade I wanted. Small notes stay quick and decorated. A big one stays usable.

Hopefully this improves your life in some way. Syntax highlight your code, deal with huge notes you wrote in the past. Maybe write shorter notes moving forward 😊. Oh, and scrollbars will now conistently show up for long notes as well.