This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-05-19
Channels
- # announcements (12)
- # aws (17)
- # babashka (6)
- # beginners (40)
- # cider (14)
- # cljs-dev (14)
- # cljsrn (8)
- # clojure (110)
- # clojure-europe (46)
- # clojure-italy (1)
- # clojure-nl (4)
- # clojure-spec (14)
- # clojure-sweden (3)
- # clojure-uk (29)
- # clojurescript (52)
- # conjure (68)
- # cursive (33)
- # datomic (9)
- # figwheel-main (11)
- # fulcro (97)
- # ghostwheel (1)
- # graalvm (2)
- # helix (53)
- # hoplon (13)
- # joker (6)
- # kaocha (1)
- # leiningen (2)
- # meander (28)
- # mid-cities-meetup (1)
- # observability (1)
- # off-topic (112)
- # pathom (6)
- # pedestal (3)
- # re-frame (16)
- # reagent (16)
- # reitit (2)
- # shadow-cljs (27)
- # spacemacs (2)
- # sql (26)
- # testing (3)
- # utah-clojurians (3)
- # vim (2)
- # xtdb (32)
https://asciinema.org/a/331770 three languages in one session 😄
That floating window fuzzy finder thing? I’ve been using fzf.vim for this but floating seems nice. Kind of want something like that for :Gcommit too now 😛
Interesting. Can’t quite imagine the lazygit UI in the same floating thing (too small?) but would love to see how you use it
Here's how that looks: https://asciinema.org/a/DM4boWMDi56r4NROHA3jY3WiM
it's also possible to configure vim-fzf to use a floating window. i have it set up that way and i find it really nice
With the new nREPL :ns
stuff I’m getting an error when doing ConjureEval (user/thing)
because it’s trying to evaluate that from within the file I have currently open (which isn’t loaded)
Ah, that's annoying. The problem is 90% of the time you want your ConjureEval
to be in the context of your current buffer (if you wanted to call a function you could see on screen, for example)
You can set b:conjure_context
to something else, but that's kind of a last resort for buffers with really weird ns forms or something.
True. Another situation where this is breaking is when I’m evaluating something from a file without a ns
declaration
I guess the ideal scenario is for :ns
stuff to not die when the namespace doesn't exist. Which I'm not sure how to solve :thinking_face:
I could imagine that maybe this also breaks some bb nREPL stuff since often scripts don’t have a namespace
That's nREPL that's throwing that error, it doesn't give me a chance to make the namespace. I have to perform an eval before your one to check if the ns exists which sucks.
Yeah if I can't find an ns in the buffer it should be nil https://github.com/Olical/conjure/blob/48b7820292ff639e2d950f331c4f96758a344379/fnl/conjure/client/clojure/nrepl/server.fnl#L84 and gets passed through as nil.
; eval (current-form): (require 'icebreaker.server.functions) ;Namespace not found: -publics
I have no idea why it would think -publics is the NS 😄
Yeah, was just gonna say
But I need to think of some way around namespaces not existing. It sucks that :ns
doesn't let you opt out of that error and say "just eval anyway"
Thought of a way around the ns chicken and egg problem too 😄 gimmie a minute and I'll have it up
Okay, pushed to develop. It should now detect non-namespaced buffers properly and also handle the chicken and egg problem of namespace definition.
Is it possible to set up a mapping that makes the log show up on the bottom or right by default? I've tried map ,lo :botright :lua require('conjure.log')['vsplit']()<cr>
and that doesn't seem to work
Pushed a change to develop that allows you to force botright
for the log window. So it'll always take up the full height or width and always appear on the far right or at the bottom. This is off by default but can be turned on by setting :ConjureConfig log.botright? true
is it possible namespace metadata is confusing conjure? I have a (ns ^:figwheel-no-load my-project.predictions ,,,)
and <localleader>eb
is giving me ; Namespace not found: ^:figwheel-no-load
in the log.
Yes, this is 100% a problem with Conjure and I need to fix that now, similar to what @U050TNB9F reported today. I'll get on this ASAP.
I'm using a regular expression to parse this stuff so it's prone to issues. I'll adjust it to ignore things that start with hat maybe? Although you can also set metadata with a map, right? That'll be hard to spot...
I don't think I've ever set metadata on a namespace :thinking_face: so it's something that slipped my mind.
Oh it's okay, I'll hop on it tomorrow, no stress. I'm sorry about the issue though, it's a bummer to get tripped up by that sort of thing, I want to aid productivity, not get in the way!
But yeah, either that or set b:conjure_context
to the buffer name and that'll also get around it.
You could maybe set that with a comment using ;; vim: let b:conjure_context="my-project.predictions":
at the bottom of your buffer :thinking_face:
yeah, I don’t do it often; really only for Figwheel’s benefit. Good tips, thank you. Not sure the modeline let works directly; found https://www.vim.org/scripts/script.php?script_id=83 as a separate script for vim and decided I can just set it manually
(other workaround: turns out fireplace and conjure coexist, so a quick :Require
does the job too).
by the by it’s deeply pleasing to be able to run two tools in parallel, as a way of weaning myself off the older one while still getting work done. I’m not sure that was intentional but I do appreciate it.
Ensuring I didn't conflict with fireplace's mappings and commands was something I had in mind, yeah 😄 there's no reason why they can't coexist.
I rewrote how the parsing works for Clojure buffers, it should be okay on develop now?
Hello all! My conjure repl is stil reporting 2.1.1 even though vim-plug seems to think I've updated to 3.2.0. Also :ConjureSchool doesn't seem to be a recognized command. Does anyone have any thoughts on what might be happening?