Fork me on GitHub
#calva
<
2023-10-03
>
Dustin Getz13:10:58

Structure editor off-by-one bug (?), i'm pressing spacebar

Dustin Getz14:10:35

switching to another tab and then coming back resolved it

pez14:10:48

Oh, wow. That doesn’t look good at all. I wonder what it tells us that switching tabs solved it… Calva has the structure of the document in a “mirror” (an array of tokens, not really an AST, but something similar). If this mirror is refreshed when the tab activates, then maybe… But two things: 1. I don’t think we refresh the mirror when a document gets active. (I’d have to check the code and confirm this.) 2. I don’t think spacebar has any significance in Calva’s structural editor. So the behaviour you have there is a mystery in that sense too. (Unless you have mapped spacebar to something?)

Dustin Getz15:10:59

it's more than spacebar, sorry i was unclear. I start by inserting a space character and then cmd-z several times, then I try ( and [ which also triggered the issue

Dustin Getz15:10:06

i dont think the mirror state is corrupted, I think the interpretation of the cursor position with respect to the mirror state has the issue. As if two indexes got misaligned

pez15:10:13

It gets to be semantics which system has the corruption. 😃 But let’s think about that as misalignment instead. We always construct the mirrorDocument’s idea of the cursor position from the cursor in the VS Code document, so there is not much chance there for misalignment. If the MirrorDocument is not mirroring the current document, though. I hold that more probable. A way to cause a misalignment, though, backtracking on my previous reasoning a bit… If a character in the document is a CR, followed by LF, then I think VS Code may correctly handle its cursor index, but the Calva mirror will not. It only handles documents with either LF, or CRLF line endings. And maybe some invisible character could cause something similar… It could be todo with cmd-z several times, I guess. We re-mirror the document quite aggressively, and maybe some quick cmd-z could throw either the mirror document out of whack. In either of these scenarios, it is still that I don’t think Calva re-aligns anything on document activate. (But I could be wrong about this). I’m half hoping this will happen to you again. 😃

Dustin Getz15:10:22

I wonder if my mac studio is simply very fast and therefore exercising a number of race conditions that aren't exercised on a typical macbook

pez15:10:58

Could be. Could be. Then we have a big problem coming our way.

Dustin Getz15:10:37

The other reason I suspect this could be the case, is that I get a lot of minor glitches (like wrong syntax highlighting, rainbow painted line-comments) that from working with you more closely these days I don't think happen on your machine

Dustin Getz15:10:37

Rainbow painted line-comments; this happened after deleting the buffer history above about this point

pez15:10:29

That happens to us with lesser Macs too. All the time. It is clojure-lsp’s semantic highlighting that gets misaligned. The only way I know to fix that is to type something and undo it. (Won’t fix it in the REPL window, most often, because reasons.)

Dustin Getz15:10:12

interesting, and presumably the mirror state does not come from LSP?

pez15:10:30

Indeed. It’s a completely different process. LSP has its own document AST, from clj-kondo, I think.

pez15:10:33

I happen to know that you think some of the highlighting is too much. You might get a more calm situation color-wise if you disable semantic highlighting. Now I am not sure if clojure-lsp allows that, but maybe it does.

Dustin Getz15:10:50

oh, my gripe about coloring is a complaint about theme designers who just bluntly assign random pretty colors to stuff without considering the meaning with respect to the user

Dustin Getz15:10:11

but if the semantic highlighing is using buggy LSP output then definitely i will disable it

pez15:10:23

theme designers who just bluntly assign random pretty colors to stuff without considering the meaning with respect to the userThat’s controversial. 😃 I think for a theme like Github Dark, this is not the case. I doubt that there is any randomness to the selection and think that the designer has applied full user meaning focus. Could be the tool-smith in me that thinks like this.

mmer14:10:08

I have been using bb as the target of the Jack-in REPL, and I have found that even though I have run evaluations they keep getting lost so I need to re-evaluate vars repeatedly.

pez15:10:47

Sounds super odd! Can’t see how Calva could cause it. Calva only sends evaluations from the user to the Babashka nREPL server. Could it be something in your bb script that causes the REPL to restart?

mmer15:10:28

No sign of a restart. I have a main set of code that linked into a core.clj file, I evaluate that first. I then have a scratch file that requires all the parts of my project so I can keep my scratch pad away from the real files, so I then re-evaluate the ns declaration at the start of the scratch file. Then I evaluate a series of defs as I debug my code. From time to time I will find I have to repeat that process and there is no sign of a restart.

mmer15:10:48

I am not saying this is Calva - I just experience it in Calva.

pez15:10:57

I’m not saying you are saying it is Calva. 😃 Just reasoning out loud.

pez15:10:32

Your scratch file sounds a bit like a Fiddle file, which Calva has some special convenience support for, btw. It won’t solve this problem, just mentioning, in case you were not aware.

Ingy döt Net18:10:51

Can I have multiple repl connections in Calva? Like for multi-folder workspaces?

pez18:10:28

Nope. That’s issue 75. 😃

pez18:10:35

Hmm, some other 2-digit issue then. Haha.

pez07:10:31

You can open the same folder in different VS Code Workspaces and start a REPL in each of them with different project roots. FYI. However, if you can get away with having a deps.edn at the root of the workspace which “indexes” the sub projects using :local/root, then you can use the same REPL for all projects, which is much nicer, imo.