What does it mean that font locking is applied? I think this is an Emacs term, but I've never really understood what it is. 😃

Correct, the theme colors applied look like they understand the language.

I see. Does the status bar indicate that it is a Clojure file?

Yes, it does.

What's missing is the list of functions that normally shows at the top of the file once I've clicked within a function in the file.

I don't quite follow which list this is. The breadcrumbs?

Yes, that's what I mean.

OK. So I tried this now. I think I know what's (not) happening. It's clojure-lsp that is not active in this file. Right now I don't remember how clojure-lsp is activated for a file, but I am pretty sure you can't configure it. Please file an issue on Calva so that we can track this. Maybe @U9A1RLFNV and @UKFSJSM38 knows more about what we should do to fix it.

I will, thanks. Have a good evening.

I think https://github.com/BetterThanTomorrow/calva/blob/published/src/lsp/main.ts#L92-L93 is how we tell vscode to use this server

Thanks @UKFSJSM38. Is this documentSelector sent to clojure-lsp as config and clojure-lsp uses it to decide if it should handle the file or not?

I think the reason VS Code treats it as a Clojure file is because of some AI stuff based on the file content.

No, this is entirely client responsibility to know when to start the server, I think that documentSelector is specific for vscode though

The server is started. That's not the problem. Or maybe I am misunderstanding you here.

There is also this: https://github.com/BetterThanTomorrow/calva/blob/published/src/lsp/main.ts#L129-L134 Even if it seems we only really exclude the output/repl window there.

Yes, maybe what could be happening is:

clojure-lsp apply semantic tokens based on clj-kondo analysis for that file, if the file has no extension, maybe kondo is not returning the analysis properly

I can't recall if kondo fallback to infer a .clj extension or if clojure-lsp should pass it manually

all of that, if the server is running properly of course

Yeah, the server is running properly. If I open a file with a recognized (by Calva) extension, we get semantic tokens and outline and things.

However, the fact that we need to exclude the Calva output/repl window extension indicates that clj-kondo is not discriminating based on this.

The server could be running for other files but vscode not recognizing that file as a clojure file, resulting in no lsp features or clojure-lsp know about that file existence

for example, on emacs, we only know we should use lsp on a file if one starts the clojure-mode on that file, then lsp-mode knows it should consider that file part of the running server

TLDR: it's client responsibility to tell server that a file is part of that LSP workspace (sending didOpen requests )

You can confirm that checking json logs between client<->server @U0ETXRFEW

That's one of the strange clues here. VS Code does recognize it as a Clojure file. I'll check the logs.

Thanks for all your help. I've added the issue: https://github.com/BetterThanTomorrow/calva/issues/1841

The clinet<->server log actually contains traffic for the extension-less file, @UKFSJSM38. I commented on the issue with a finding.

@UKFSJSM38 I’m guessing it’s related to the file extension checks in here: https://github.com/clojure-lsp/clojure-lsp/blob/a4a88439e0360a8dbdd8b89885e4c23a6c6f6621/lib/src/clojure_lsp/shared.clj#L107

Yep, yesterday I tested changing it and it worked, I was just double checking if there was other features using that that could be negatively affected

I think the biggest thing is probably that clients can’t be as lax as before. If you now treat every sent file as clojure code it’s going to give interesting results if my client just sends everything 🙂 But that would be a bug in the client so we should be aware of it but not base decisions around it

Yeah, I think it's a better tradeoff from server side view

It still won’t pick up the files if they aren’t open in the client, correct? But doing that would add a bunch of new problems 😞

Exactly

I guess it's fine for now

Yeah, adding to much complexity for a very rare use-case doesn’t sound like a good idea

To me it's unclear what the alternative would be. I see only these two: • Limit on the file extensions, and let some Clojure files be treated wrongly • Don't limit on file extension, and the client gets what it asks for

Yes @U0ETXRFEW. Although file extensions will still be limited a bit in the sense that unknown extension files will only be analyzed when the client tells the server about them (mostly on open). So if you have a dependency on a file with an unknown ending and you don’t open that file, the dependency would be show as missing.

Yeah, I guess analyzing everything in the project is not an option. 😃

Yes, I think supporting clojure-lsp features on the opened file is already enough to solve the issue for most people