Fork me on GitHub
#calva
<
2020-05-11
>
orestis06:05:33

One thing that I love about Emacs / Clojure Mode / Paredit is that I can press a closing bracket e.g. ) or ] and it will automatically bring all the trailing parentheses/brackets to the current line. I can do the same in Calva with ctrl-J but it leaves a space I have to manually delete.

pez09:05:39

Not sure I am following, but pressing tab folds the paren trail. I've deliberately made it something that doesn't happen as-you-type b/c I like for the user to be in control of this.

orestis09:05:34

Hah I never use tab in emacs, itโ€™s a different muscle memory.

orestis09:05:38

Iโ€™ll try using tab more. This and the delete forward sexp is my main tripping points. I can customize the latter though.

pez10:05:53

You can customize tab as well.

orestis06:05:14

One other thing with Calvaโ€™s paredit is that sometimes when Iโ€™m slurping expressions it will not cross some boundaries. Emacs will happily keep slurping through {} [] ()

pez09:05:09

I had this in a dev branch somewhere, but then I couldn't easily make it reformat past the currently enclosed form so scrapped it b/c w/o feedback it got a bit dangerous. But last week I made a few changes to the as-you-type formatting, that might allow this. Please file an issue. ๐Ÿ˜

pez16:05:15

Here's the issue and the PR. Does it seem like the thing you are asking for here? If so, maybe it is reasonably simple to wake up. https://github.com/BetterThanTomorrow/calva/issues/554 https://github.com/BetterThanTomorrow/calva/pull/555

orestis17:05:23

Iโ€™ll try to have a look at trying PRs locally

pez06:05:49

Here's a VSIX where I think I might have gotten it to work. It is a bit unintutive to me yet, so can't fully judge it. ๐Ÿ˜ƒ Can you give it a spin? https://6124-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.101-slurp-enclosing-554-124fb68f.vsix

pez06:05:33

Test both backwards and forwards slurp. It is the backwards one that twists my brain mostly.

pez14:05:50

This is now released. File an issue if it misbehaves. ๐Ÿ˜ƒ

orestis16:05:00

Woot! Sorry for not testing earlier !

Cas Shun14:05:33

Curious if there's been any progress on this issue: https://github.com/BetterThanTomorrow/calva/issues/434 , I'm constantly having issues figuring out errors when using inline evals

Cas Shun14:05:36

it's particularly annoying because inline eval *e just gives me a clj-kondo error, not the error of the last eval

pez16:05:19

clj-kondo error?

pez16:05:54

I'd welcome a PR for that issue, anyway. ๐Ÿ˜ƒ

Cas Shun17:05:17

@pez every error is something like #error { :cause "clj-kondo.core" :via [{:type java.lang.ClassNotFoundException :message "clj-kondo.core" :at [.URLClassLoader findClass "URLClassLoader.java" 382]}] :trace

Cas Shun17:05:34

unless I type in the repl window itself

Cas Shun17:05:40

(who does that though?)

Cas Shun17:05:42

To be clear, that's if I inline eval *e

borkdude17:05:30

@auroraminor Maybe it helps if you post the entire stacktrace? (in a gist or upload as file)

borkdude17:05:41

I think this might happen because some piece tries to invoke clj-kondo.core/run! or something else while the namespace has not yet been required

borkdude17:05:47

user=> clj-kondo.core/x
Syntax error (ClassNotFoundException) compiling at (REPL:0:0).
clj-kondo.core

borkdude17:05:05

clj-kondo does warn about this though ๐Ÿ˜‰

pez18:05:48

Ah, yes, I was about to say it couldn't come from Calva. ๐Ÿ˜ƒ

bringe19:05:40

My thought was the recent decorations addition as well. I wonder if we should put the require call in the getLintAnalysis function so that it's called before every call - after it's required the first time it shouldn't cause any overhead I think, but still, it should be required any time execution reaches that point since the require is in the activate function for the decorations

bringe19:05:51

@auroraminor If you can provide a reproducible project/situation that would be much appreciated.

bringe19:05:49

Nvm I've found a repro-case by not loading clj-kondo as a dep in the connected repl, which should not cause this problem. I will investigate simple_smile

borkdude19:05:56

@brandon.ringe you can use requiring-resolve maybe

borkdude19:05:26

(but that depends on 1.10, might not be good for Calva, but you could re-implement it)

bringe19:05:23

Thanks, I'll look into that

bringe20:05:13

Found the issue =D, will fix soon

dabrazhe21:05:08

Perhaps I missed it as a feature), but I cannot press the Up arrow in the Calva repl prompt to cycle through the previous commands. Is it my buggy setup?

bringe21:05:05

If you're in multi-line edit mode, which I think is the default, it should be alt+up

bringe21:05:20

Single-line however is just up

dabrazhe21:05:39

yep, it means single line is not working as expected. will restart

bringe23:05:48

@dennisa Hmm.. if it persists, please create an issue.

dabrazhe07:05:39

I just checked on Windows as well. It's the same issue: i evaluate an expression say (inc 0). Press arrow up, nothing happens. Press Alt-arrow up, then i can go back to (inc 0) and cycle the old ones. Are you sure it's not intended behaviour : ) ?

bringe16:05:30

This is the intended behavior for multi-line repl window mode. I'm somewhat confused now about what you're saying, lol. If it's working with alt+UpArrow in single-line mode then maybe some key bindings were changed. I'd check your keyboard shortcuts

dabrazhe10:05:21

{ "key": "up", "command": "calva.replWindow.historyUp", "when": "calva:replWindowActive && config.calva.REPLWindowPromptKeyMap == 'single-line'" }

dabrazhe10:05:04

The shortcut is the default one, arrow up

bringe17:05:41

Weird, an issue with repro steps would be very welcome simple_smile

bringe23:05:56

v2.0.100 is out with a couple fix / maintenance items