Clojurians Log v2

Hey there, Conjure looks slick. I’m doing the :ConjureSchool and I’m having trouble with Eiw:

; eval (selection): lesson
; Compile error in 'lesson' 

Where my cursor is like this:

school.les<cursor>son-6-message

I suspect I have to somehow tell vim that words in Lisps can contain dashes?

Oh yeah! I think someone else hit this a while back, let me recall where that setting comes from

So I think it's defined by the iskeyword option but I can't work out which plugin of mine is adding - to it

Ah so if you :set lisp it should work as expected @orestis, I need to have a think about this. Pretty sure my nvim is doing this automatically which is why I don't encounter it but I can't work out where it's coming from... maybe it's some other setting that happens to configure set lisp for me, I have no config for it in my dotfiles.

> 'autoindent' must also be on for this to work. Perhaps this is it!

I might just remove that part from the school or change it so it doesn't rely on the hypen. Or if I can get to the bottom of it I'll explain how to get your nvim to treat lispy words correctly inside the school

set lisp makes it work :)

Awesome! Well I can't find the thing in my config that sets this but it seems like almost all lispy syntax support plugins do it, so I guess I'll set it for you in the future too!

Thanks for hi-lighting this issue.

Another quick question: Cider (and Calva) special-case the (comment …) form so that top-level evaluation ignores it. Makes it really easy to work with rich-comments.

the question is, does Conjure have something like that, or if not can I override it somehow?

All lispy syntax plugins set this, it doesn't get set when I do a hack to give you syntax for fennel files in the school. Worked it out and will work around it.

Hmm this has been thought about quite a few times but never implemented. I still have something similar on my "maybe" backlog. My usual approach for things in comments blocks if I want them to be runnable as a group is to wrap them in a do this way it works for me and my colleagues in spacemacs

Still happy to consider it though!

You still have to navigate to the end of the do block, right?

Oh no! Not at all, Conjure's mappings seek the beginning and end of the form

Spacemacs do not

They require you go to the end

Ah, so you can put the cursor on the do itself, and ee will do the right thing

Yep, anywhere on the do will evaluate the do as a whole.

Unless you go another form deeper

(do| (+ 1 2)) where | is the cursor will eval the do

(do (|+ 1 2)) will evaluate the +

With <prefix>ee, whereas <prefix>er will evaluate the top level form regardless

There was talk about making er ignore the comment block part, but I'm still not sure about that.

That would get you the behaviour we're talking about

The other thing you can do, put a mark on the do you're interested in then use <prefix>em{mark key} to evaluate the form at that mark.

Which I use a lot

The mark is definitely useful.

the way I see it, evaluating the top-form when it’s a comment is always going to be a nil, so opting-in to the tweaked behaviour is probably not dangerous for most people.

I’m floored at how fast nvim+Conjure is to eval things. I went from Emacs to VSCode which was definitely a huge hit in performance, but I’m amazed about how I get color-coded results back so quickly.

Big thanks @olical for doing all this work 🙂

Did you find Emacs faster then VSCode? I was using Spacemacs on an ~2015 Macbook Pro some time ago and it was staggeringly slow for me …

I would like to see a way for the comment block to be ignored. I have several forms inside of one (to try things out). I don't really want to wrap the entire thing in a do (or each of the forms inside the comment))

So a nice way to pretend that if evaluating a form, for the comment block to be ignored gets my vote! and when evaluating the entire file/buffer for the comment block to act like a comment block and the forms inside aren't evaled 🙂

🙂

I used vs code but after plain Emacs, not spacemacs. Emacs was definitely faster than vscode but I attribute that also to the plugins, Cider is much more polished and efficient.

Plain Emacs was plain fast but the nvim startup is comically fast.

I'm rethinking my standpoint on eval root form :thinking_face: I'll take a look at it in my next chunk of work

You're more than welcome! I hope you enjoy and I hope I can keep improving it for you! No hard feelings if you go elsewhere for you evaluation needs too 😊

I tried to like emacs / spacemacs (tried both angles) for about a year, then went back to vim+fireplace but missed some things from emacs land. Now we have Conjure + Aniseed 😅 although it took 3-4 years...

Startup time and statefulness in weird places + non-evil key bindings leaking through and surprising me really put me off

🙂

I assume something was wrong with either the machine or my setup, but Spacemacs was slow for me to the extend it was difficult to use …

@olical what were the things you missed from Emacs-land? I really tried liking it and really like the idea of easily customisable/moldable environment

I think the only thing was interactive lispy interaction with the editor itself, which is why I built aniseed

But I didn't really like elisp so I think Fennel running in LuaJIT is better in basically every way (for me)

The only thing I miss from Emacs is m-x was

Other than that, I thought the freedom in UI led to inconsistencies. Major and minor modes confused me and felt too idealistic and narrow (probably just didn't understand them). I'd regularly get into states where something was off and I'd just have to restart. Package management felt absolute awful and FAR too complex in comparison to what I have in nvim

I suppose you could use something like :Clap command for that https://github.com/liuchengxu/vim-clap

For m-x I mean

I love the mark thing. Would be super sweet to have something like that in Calva.

I think vim-iced added it after seeing it in Conjure, might as well continue the trend 😄 I think it's a great way to eval things.

One core part of the functionality though is that you should be able to do it from another file, if you can do that? So if I do mM on some thing I'm interested in running then go to another file elsewhere in the project I can hit ,emM and have it eval the mark in the original file under the right context.

So if you add it, definitely try to get that part! It's suuuuper useful in some very specific things. Saves you buffer hopping over and over.

(also uppercase marks in nvim are persisted to disk (I think), so these magic eval mappings persist between restarts!)

Apropos the special case of regarding comment form as creating a new top level. I've never heard anything remotely like a complaint about Calva behaving like that. And I would sorely missed it myself if it wasn't there.

Thanks for the pointer about cross-file marks. That will definitely need a bit tricky to get into Calva, but the whole mark thing would be tricky anyway. Haha

Expanding on my m-x comment - Emacs felt as it didn’t require me to bind every little obscure thing into a key, as I could m-x and start typing, with autocomplete usually finding the right thing. Vim suffers from too much terseness in the commands...

@pez Thank you very much for the feedback! That's hugely reassuring, I've been on the fence because I'm scared of someone evaluating a root form on a comment expecting it to do nothing but return nil (I don't know why you'd do this but still) and instead having EVERYTHING inside the comment executed. Which could be VERY bad.

Got it yeah, I agree with you there

So you map what you need access to quickly and m-x for everything else

My original approach for the comment block conundrum was to allow numerical prefixes to eval root and eval current form. So 1,er or something would eval one form in from the root.

But it's a bit too clever and pretty hard to implement until I get tree-sitter support everywhere.

Yep. I also need to figure out paredit in insert mode.

I use vim-sexp and have done for years, I never really fell in love with paredit. vim-sexp feels a lot more vimmy to me

Also never got on with parinfer

A big Emacs plus is also accepting that mouse is a thing for things like hover on a word to see eg a longer error. Not sure if neovim adds something there.

I think that's required if you're burying info inside things and inventing new UIs for stuff. If everything you do ends up in a buffer (maybe with some folding?) then you don't need to expand things. Trade offs for sure. I don't think nvim brings anything new to the table here, I have set mouse=a which allows me to interact and select nicely, but it's not useful other than that. The main difference there I guess is emacs isn't tied to the rules of a terminal (unless you use the tui)

I kinda like the terminal restrictions since it forces you to do everything in text, which can allow more things to plug together. I felt like some of emacs UIs were a whole new thing I had to learn with their own rules. Vim is just commands, mappings and buffers.

Having images and varied font sizes could be nice, but it's not a dealbreaker

Not sure I understand you correctly, but for the record. Calva does not evaluate everything inside the comment form. Instead it behaves like if the comment form creates a top level, so if you evaluate top level form, when inside a comment form it will evaluate it as if the comment form was the whole file. Example:

(comment
  1
  (vec (repeat 2 |[:foo :bar]))
  3)

(The Evaluate current form command has no such special case.)

Oh! :thinking_face: I was thinking that it would turn comment into an implicit do. I've clearly misunderstood. So eval root form would basically not count the comment as a form and instead look at whatever top level form below that your cursor was in.

Yeah not an implicit do - it’s as if the comment wasn’t there at all so you can go line-by-line

Then I can see how you were reluctant to add it. 😃

Is there an equivalent to fireplace’s :Eval? I used this a fair bit for eg. map ,r :wa\|Eval (juxt.clip.repl/reset)<CR> to kick off a tools-namespace-ish refreshes in integrant/clip/mount

@rgm :ConjureEval (+ 1 2)

i have a similar mapping, ,ep => :ConjureEval<space>

doh! in the main doc and not the nrepl one. Thanks.

i think refresh is also supported out of the box with conjure, although it might require nrepl middleware

try ,rr

ah, ok. saw that refresh, but wasn’t sure if it was a ctns-style unload-reload

🙏

Yep! Sorry, that's usable in every client so it's in the core docs, I do feel like I could make these thing easier to find. Right now you need to know to check :h conjure and :h conjure-CLIENT

Which kinda sucks

Not sure what I could do about it though

Yep! The refresh tooling is built in and supports a "before" as well as "after" function https://github.com/Olical/conjure/blob/d9d514db3ef7fcf36bacc402aba511663a73bfbc/doc/conjure-client-clojure-nrepl.txt#L185-L198

All good. No worries.