A little late but here's the PR https://github.com/BetterThanTomorrow/calva/pull/949
(I branched out from published
since in was only a doc change, hope that's ok)
Let |
be the cursor.
If I'm in this text state (foo/bar|
and I move paredit.backwardSexp
I end up in (|foo/bar
.
I'd like that to end up in (foo/|bar
.
Is there a movement I can use that's a mix between sexp and words?
Pondering on a condition in the when bit to fall back cursorWordLeft
when there's a symbol to the left (right respectively).
calva:symbolToTheLeft
could that become a thing?
Also, I'd like to disable inline eval feedback. I find it's never useful, and otherwise annoying.
Kill sexp should also add it to clipboard, because you more often move it than ditch it.
In Calva you instead use a select command, then regular cut to clipboard.
It could. But it is a bit tricky to implement. Will elaborate a bit on this, but can’t right now, so for now, tricky because reasons. 😃
If we can simplify the selection commands, it would get less of a finger gymnastics thing.
I don't think this is going to happen. We try to keep the amount of settings down to keep things simple. Curious about your workflow, now.
Most of the time the data I want to look at is big enough that showing it inline is showing just it's beginning, so I look in the repl output or reveal
Makes sense. The long results can be a bit confusing inline as well. It’s not really clear that they are truncated.
I have ctrl+arrows paredit movement and ctrl+shift+arrows paredit selection now. Other than that I removed a lot of Calva's defaults overriding "standard" commands.
We used to have hovers for the inline annotations that would show the full result. Those may be brought back soon.
I don't find this to be true in my workflow. Though I'm unsure whether a majority of users would think so.
Curious what you have slurp and barf remapped to, if anything?
I don't use those
Sometimes I jack-in but nothing happens in the output window. After a few retries it works. How am I supposed to solve this?
It has happened again. I opened vs code, changed something in the project.clj, jacked in, and this is the output:
This has been happening pretty regularly for me as well. The only way I’ve known to fixit was to disconnect the current REPL and jack-in again.
Can you file it as an issue, @christiaaan? That screenshot is a good clue.
I’m also curious about what you changed in the project file.
I ran into this again today, first three images are when it wasn’t working. I reloaded vscode to get it working again, output from a successful jack-in is the last image. The only difference I see is the socket closed
message.
I see Jack-in process kill requested. Did you kill it intentionally at any time?
No, I am doing the jack-in command using a keyboard shortcut and selecting the project type from the action menu
Thanks. Jack-in starts with killing any ongoing jacked in processes. But it is a bit strange that you get two of those prints. Then again, you get that even when it works, so it is probably not the issue at hand….
hmm yeah wish I could be of more help. Any other tips on what to look out for next time I run into this?
You can run Calva in development mode and then when it happens you can try chase it down with breakpoints. That is how I always use Calva and it is not particularly slow or anything.
Since it happens to you somewhat often, and never happens to me, you’ll have much higher chances at figuring this out than I have. 😃
Du you have any error messages in the dev console that seem related to Calva?
Ok, maybe I'll see what I've been missing:
• moved slurp/barf on: alt+shift+(<|>)+shift?
• <|>
chords are nice they hint parenthesis movement direction
• shift
has the action on the left side of the cursor
I am not following.
https://github.com/clyfe/vscode/blob/main/keybindings.json#L53-L72
I see. I do like ctrl+alt+.
and ctrl+alt+,
for slurp and barf, as you suggest. I thought about these combos earlier, since as you say the last keys are also >
and <
on the keyboard, suggesting right and left, and also are adjacent to each other in that order.
And these don't overlap any vs code bindings
Then we could make ctrl+leftArrow
and ctrl+rightArrow
map to backwardSexp and forwardSexp navigation. And this maps well to default navigation in vs code.
I'd be behind a change in the defaults to those
We should change the defaults for non-mac. But I’d be wary to take the scheme for slurp/barf from someone who don’t use them. 😃 Rather do something like alt+arrows
on Windows. If we leave ctrl+arrows
alone there it will move between “words” and we could keep ctrl+alt+arrows
for form-movement for now.
As I see it the big and general issue is that we have unwittingly hogged a very common shortcut for word-movement and used it for slurp/barf. There is a case for saying that in Clojure code forms are words, so the idea with hogging the default word-movement is worth pondering. But if we do we should also do that on Mac (`alt+enter` there) and also change the corresponding selection commands on respective platform.
Would you mind putting your points on this issue? https://github.com/BetterThanTomorrow/calva/issues/950
If any changes are made, they certainly need some discussion and consensus, I can see
Now it's working fine. Remind me how to get to the console again, and I will post my output here.
I know shortcuts are difficult to get right, in our case, with so many paredit commands that we don't want to just leave with no binding, but I'm also tired of these conversations 😂 . There's got to be some better way.
At least we can point people to the issue now until some solution is agreeable
I don’t think consensus is very usable in general, and about impossible in this particular space.
There is no way you will ever get rid of these discussions, as long as Calva has default keybindings. 😃 But, certainly we should fix the downright mistakes we’ve made. And I also like the suggestion here to mimic the movement primitives. Like we have done with selection (`shift` + movement).
Happy to hear it is working! Hoping it will keep like that. 😃 Help menu -> Toggle Developer Tools.
This is an Emacsism that I have chosen not to bring over to VS Code. See note in the Selecting section of the Paredit guide: https://calva.io/paredit/#selecting
Calva version 2.0.151 is released. 🎉 :calva: It contains a fix for the debugger on Windows. I realized while working on other changes that the debugger was hanging on Windows. I apparently broke it with recent changes that fixed the debugger's ability to step into local jar dependencies 😬 . I've now implemented a fix that keeps that ability and works on both Windows and Unix-based systems.
The kind of bug one fixes a lot of times before it is fixed. 😃
Path issues and dates, forever the burdens of the developer
A former colleague of mine said it was printers and users.
I had this for a while also, but an uninstall/reinstall seems to have fixed it. It happened only when I did something in the editor prior to trying to jack in. If it happens again I'd try to get the developer tools output.
I'm having some trouble getting Calva's test runner working when I start the repl from the terminal (with test alias bringing in the paths) and then connect to the running repl from Calva. It works fine when I jack in from Calva itself. Is that expected behaviour?
Calva doesn't even know the user deps.edn exists. So the difference there is probably one of not having the alias defined vs having it defined. To tell Calva about aliases it should use at Jack in, I think the menuSelections property in custom connect settings is the only way. https://calva.io/connect-sequences/
@allaboutthatmace1789 I had a bug when using hyphenated names for aliases specifically when adding the alias via calva.replConnectSequences
, but adding the same alias into the deps.edn local to the Clojure project works with hyphenated names (sorry, should have raised an issue)
Ah, yes, that too.
I tried without hyphen, i.e. called the alias just calva in .clojure/deps.edn. It's still launching with the same args:
clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version "0.8.3"} cider/cider-nrepl {:mvn/version "0.25.6"} clj-kondo/clj-kondo {:mvn/version "2020.04.05"}}}' -A:calva -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
Should mention, I'm launching it by adding :calva
to the Calva: My Clj Aliases setting
Which args do you want it to launch with?
When I launch it with that alias in the project deps file, it launches with this;
clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version "0.8.3"} cider/cider-nrepl {:mvn/version "0.25.6"} clj-kondo/clj-kondo {:mvn/version "2020.04.05"}}}' -A:calva
i.e. the same thing without -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
. I might be wrong, but it seems like those extra things are overriding the arguments in the alias - specifically the reveal middleware. I'm just not clear on why those extra things are being addedThey start the nrepl server so that Calva can provide its services. Since the alias you provide has it’s own main options, Calva does not add its default main options to the command line. There can only be one main. 😃
I'm sorry, I'm not following. I get that there can only be one main, what I don't get is why -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
is being added in one case (where the alias lives in .clojure/deps.edn) and not where the identical alias lives in the project deps file
That is because Calva does not read the alias definition in the user profile, so it can’t see that there is a main option there. There used to be docs about this. Not sure when we lost them…
Ahhh. So if it's in the project deps, Calva can figure out that the alias has main opts, and chooses not to add it's own. But if it's in the user deps, it can't get to it, so it thinks it needs to add them.
Yes. Well worded. If you feel up to, I’d welcome a PR to the docs so that this behaviour is not as secret as it is today.
Thanks, if I get a chance later today I will give it a go
Hi. It could be that your repl doesn't have the required dependencies. The test runner relies on cider-nrepl. When you run jack-in, you can see in the command what dependencies are added. You can copy this command and run it in another terminal, then connect, and it should work.