Support LSP Semantic Highlighting for File Previews

[pattobrien]

Is your feature request related to a problem? Please describe. LSP-based semantic tokens are now supported with the upcoming nvim v0.9 release (available on nightly build). This allows syntax and semantics to be highlighted without the use of Treesitter. It'd be great if the previewer APIs allowed for highlighting with LSP as well, and/or enable this option as the default.

Describe the solution you'd like Semantic highlighting in the editor should match the highlighting of the previewer.

Describe alternatives you've considered I assume it should be possible to somewhat do this via the job_maker / highlighter utils under telescope.previewers.utils.

[tjdevries]

Hm, i think this would be pretty hard -- I think it could work if you had the buffer already open, but it would be hard to get the LSP to attach to a file otherwise.

[pattobrien]

Hmm I see. I'm not familiar with telescope's architecture, but what exactly would be difficult about doing so? I would expect that the preview is no different than opening any other buffer, which (if within the scope of the already open project) LSP should already have semantic info readily available for - not sure if it would be quick enough for this use case though.

I only have direct experience working on the Dart language server, but IMO it seems more likely for each language to provide official support of LSP rather than both LSP and TS, so it might be good to consider this, at least in the long term.

[tjdevries]

cause we usually don't actually open the file -- because that would be really slow to do for every file in your whole repository. And people can have arbitrary effects run when you open files. We usually read the contents into the buffer and then do some other stuff on top of that.

I'm not saying we can't do it, I'm just saying it's not quite so simple as it seems.

[tibimunteanu]

The lack of lsp highlights in previews is what is keeping me from leaving vscode for nvim. I hate that I have to use hacky vscode to vim extensions that are missing a lot of vim features, but having to deal with lsp and treesitter highlights which don't agree is even more frustrating.

I get that the lsp highlights for previews may be slower because you would actually have to open the buffer and maybe attach an lsp if it's not already running, but make it an option. Have it default to treesitter highlights for people who don't mind the differences.

My ideal telescope setup would be with no preview by default, and have a map to open the preview on demand, which would open the buffer for the preview, use lsp highlights and close it when I close the preview or move on to another entry in the results list (if it points to a different buffer).

For example, Treesitter has no idea about types that come from imports and are not declared in the current file, and will highlight types as variables.

[xzbdmw]

I think you are possible to write a custom treesitter capture group to capture import xxx as types and highlight xxx.foo() differently