I think clojure-lsp already respects bb.edn

Ok I will continue and see. Thanks

yep, clojure-lsp already does that

Maybe @UKFSJSM38 is the best person to help with this.

could you show a video or so explaining what is that feature?

There’s a demo GIF that the VS Code team made here: https://code.visualstudio.com/updates/v1_70#_editor-sticky-scroll

ah cool, interesting

how that behaves on clojure right now?

is it everything ignored on is there something "sticking" already?

if var definitions or namespaces are already sticking, probably they are using the result of the textDocument/documentSymbols from LSP which is a clever idea

so we would need just to add keyword definitions there which is a issue opened recently on clojure-lsp, but would be nice to confirm my first question

It works on Clojure code. There are three options for what it should use for determining what should stick. Which may be a setting for you to experiment with @UTFAPNRPT.

I have experimented with the options. I’ll describe what I’m seeing, even though you may have already experimented and already know this. By default (outlineModel) the same items that show up in the outline are the same items that are “sticky” when scrolling. Specifically: ns forms act like an “outer wrapper” and are always stuck to the top (which I’m still not sure if I like that or not); then defn and def forms are also sticky right underneath the ns form, but they replace each other as you scroll. That is, you only ever have one defn or def stuck right below ns. If I switch to folding or identation, then many more things start to become “sticky”, and I’m not even sure the distinction between the two, but basically anything that VS Code recognizes as a foldable or collapsible range, the same items where VS Code gives you a disclosure chevron in the left gutter, those all now become sticky. In these two modes, reg-event-fx becomes sticky, but so does a lot of other stuff. Too much, in my opinion. Hence my original question how I could get reg-event-fx to be recognized in the outline, and then it will automatically become sticky.

Thanks, @UTFAPNRPT. I haven’t experimented much with this. I disabled it after a few days, because it got too confusing to me. It would take me a lot of time to get used to that the lines in visible part of the buffer are from somewhere else in the file. The confusion remained after some days, and remained worse than the benefit I drew from the feature. 😃

You have a good point, @U0ETXRFEW. I just noticed it for the first time today (sometimes I am slow to update VS Code), but after updating I certainly did notice it right away, it was obvious that something was definitely different. I’m still trying to decide if I like it or not.

I’ll keep kicking the tires on it for a few days. I’m not sure how often I get “lost” within a single file. We’ll see.

If my function takes up more than a screen height, I rather need to fix that than get help with finding my way around in it. 😃

However, I now sound like I discourage others from using the feature. I have no opinion on what other do! Just reported on my own results from testing it out.

Keeping functions small is definitely common in Clojure. But I’ve noticed an exception with clojurescript and hiccup. Conceptually the function is small but expressing it in hiccup takes a lot of space.

Indeed.

Bringing the opposing opinion, I love and use this feature. Especially going from js/ts to clj. If the solution to this involves registering reframe keywords as symbols that would be a dream. If then, that would make Go To Definition somehow work (better) for reframe subs/fx/event-fx's I could cry haha. Using kondo to treat them as def* doesn't seem to work very well. Anyways, I'll clarify that I specifically want the stickiness for the reframe stuff

would be nice to check if any of these 3 providers use LSP, if yes we can support it indeed

The outline model is provided by clojure-lsp, @UKFSJSM38.

Do you know by which LSP method?

Not really. It just happens, I thought. But I can check…

Please, so we can know for sure where to change and open an issue in clojure-lsp to support that

I can’t see anything in the Calva code regarding this. The clojure-lsp trace when starting the server looks like so:

[Trace - 1:22:08 PM] Sending request 'initialize - (0)'.
[Trace - 1:22:09 PM] Received response 'initialize - (0)' in 148ms.
[Trace - 1:22:09 PM] Sending notification 'initialized'.
[Trace - 1:22:09 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 1:22:09 PM] Sending request 'clojure/serverInfo/raw - (1)'.
[Trace - 1:22:09 PM] Sending notification 'textDocument/didOpen'.
[Trace - 1:22:09 PM] Sending notification 'workspace/didChangeConfiguration'.
[Trace - 1:22:09 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 1:22:09 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 1:22:09 PM] Received request 'client/registerCapability - (1)'.
[Trace - 1:22:09 PM] Sending response 'client/registerCapability - (1)'. Processing request took 1ms
[Trace - 1:22:09 PM] Sending request 'textDocument/documentSymbol - (2)'.
[Trace - 1:22:09 PM] Sending request 'textDocument/documentSymbol - (3)'.
[Trace - 1:22:09 PM] Received response 'clojure/serverInfo/raw - (1)' in 3ms.
[Trace - 1:22:09 PM] Received response 'textDocument/documentSymbol - (2)' in 8ms.
[Trace - 1:22:09 PM] Received response 'textDocument/documentSymbol - (3)' in 9ms.
[Trace - 1:22:09 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 1:22:09 PM] Sending request 'textDocument/semanticTokens/full - (4)'.
[Trace - 1:22:09 PM] Sending request 'textDocument/semanticTokens/full - (5)'.
[Trace - 1:22:09 PM] Received response 'textDocument/semanticTokens/full - (5)' in 0ms.
[Trace - 1:22:09 PM] Received response 'textDocument/semanticTokens/full - (4)' in 2ms.

The items in the outline are called symbols so maybe it is textDocument/documentSymbol?

yes, that's my guess too

if clojure-lsp doesn't start, does the outline works?

clojure-lsp is the only provider. No clojure-lsp, no outline.

got it, so makes sense to include that on documentSymbol

It would be good is this could be solved in some general way. I.e. not re-frame specific. But I think you are planning something more general, right?

yes, there are keyword-definitions analysis which we already use for some features including re-frame support, so the idea is to consider them as well