Don't return invalid region from lsp-semantic-tokens--fontify.

[kurnevsky]

Currently it returns 0 . 0 which is outside of the buffer, (point-min) is 1. It's better to return nil instead because such invalid region might break other packages, i.e. indent-bars.

See jdtsmith/indent-bars#117

[jdtsmith]

It also needs to call the downstream function no matter what. These functions should only expand, not contract (or zero out) the indicated region.

[kurnevsky]

It also needs to call the downstream function no matter what. These functions should only expand, not contract (or zero out) the indicated region.

But then the downstream function will colorize that region, won't it? This will result in inconsistent syntax highlighting and flickering once lsp-mode gets semantic tokens from lsp-server. We don't really want to get colors from the major mode here.

[jdtsmith]

But then the downstream function will colorize that region

Yes, but otherwise you are "hogging" jit-lock all for yourself, and other packages which need access to jit-lock updates simply won't work. The way eglot semantic and semel are solving this is to decorate text with semantic-based text-properties as/when available, then, in font-lock (just font-lock-keywords as Stefan is recommending) turn those into 'face. So if there is no semantic info yet available, font-lock wins, but once available, lsp wins.

Honestly, I don't think lsp should need to advise font-lock-fontify-region-function at all; it can just use keywords. See this discussion for more: https://lists.gnu.org/archive/html/emacs-devel/2025-10/msg00024.html.

Note that indent-bars does need to wrap the f-l-f-r-f, because (with scope highlighting), fontification depends on point, which is unusual. So rather than constantly redoing all of font-lock as you scroll point around in the buffer, we arrange to update only the bars (unless the rest of font-lock is actually necessary).