vim 2019-05-21 | Slack Archive

Olical12:05:50

Any thoughts on these bindings so far? Thought now's the time for some breaking changes to defaults so input is appreciated! https://github.com/Olical/conjure/pull/37/files#r285999533 * e is anything eval related. * t is anything test related. * c is anything meta to do with Conjure itself. I'll probably add f for formatting things and r for reloading things with tools.namespace soon.

mynomoto18:05:08

I have a confession, I remapped everything to work more like fireplace 😱

Olical18:05:52

That's perfectly fine! That's why I let you turn off the defaults :D I'm excited to hear that you've tried it though!

mynomoto22:05:51

Oh I probably should have told you that I'm using it full time for several weeks now. It is great!

dharrigan12:05:16

Seems sensible and mnemonical (is that a word?) 🙂

Olical12:05:23

Yep, that's the word to describe what I'm going for!

Olical12:05:41

So you can kinda match up words to each first character, which a bunch of vim is designed around. Except when it's not...

Olical12:05:24

I'm aware that vim-sexp + vim-sexp-mappings-for-regular-people may conflict with some if I'm not careful, not sure about any other popular plugins using lots of localleader mappings.

dave13:05:39

looks great to me

dave13:05:59

i've always been a fan of the "categorize actions with a prefix key" idea

dave13:05:21

@olical what's the difference between :ConjureEvalBuffer and :ConjureLoadFile?

Olical13:05:52

One will send the entire buffer as is, the other will call load-file from disk.

Olical13:05:57

In theory, you'll get the same result.

Olical13:05:11

In practice, it's saved my ass during development where I broke Conjure's regular eval 🙃 (I can then load-file with a fixed version so I can regular eval again)

dave13:05:56

ah, gotcha. that makes sense

dave13:05:22

i could also see that being useful if you've made a bunch of changes to the buffer and you haven't saved it yet

Olical13:05:23

I'm not so sure about the binding though, most of the time you want eval buffer I think. Why make that further than eval file :thinking_face:

dave13:05:34

and then you realize you want to try something out using the version you have saved to disk

👍 4

Olical13:05:35

I use eval buffer 99% of the time.

dave13:05:17

you mean further in terms of how far your finger has to travel?

dave13:05:24

because anecdotally, i use the dvorak keyboard layout, and b is slightly closer for my finger to reach than f 😄

dave13:05:54

they're about the same though

Olical13:05:06

Haha okay, well that make sense. I think mnemonic makes more sense than distance when they're that close. I'll just have to train my brain to get to this new layout 😬

dave13:05:46

i think it's probably reasonable to optimize for qwerty users' comfort. us weirdos who use other layouts can always create our own mappings if we find any we don't like 🙂

dave13:05:15

mnemonic is totally more important, also

dave13:05:58

that's why i find vim so pleasant in dvorak. it doesn't really matter how far away the keys are, because i've sort of trained my brain to think in terms of mnemonics because that's the vim way

dharrigan13:05:17

You know what would be cool, and more of a neovim feature (acid?) is the ability to show the evaluted expression beside the form, like in emacs

👍 8

Olical13:05:15

Yep, it's floating around in my head 😄 but it would only work for small outputs, like one line things so it's not super general. So I need to think about how big things are displayed, like does the log buffer then become optional etc

Olical13:05:12

I like the log buffer because it works like a REPL output you can edit and interact with, if you make it pretty and inline it looks nice but it's not useful if that makes sense? So I might add it as a pretty thing for when your eval output doesn't print anything to avoid opening the log buffer on every eval. Something to think on for a while I think.

Olical14:05:34

Also considering using that space for inline doc strings for what args the symbol under your cursor takes

dave14:05:50

acid.nvim does this

Olical14:05:41

Yeah, it shows the eval result right? I'm just wondering what happens when the output is 100s of lines long. I design Conjure around my day to day work with lots of big maps so I quite like it in a buffer I can work with. Maybe defaulting to inline with having the full formatted thing a keypress away would be cool though!

dave14:05:32

i think the sweet spot would be if you provided options to allow the user to specify if they want results in the eval buffer, or inline, or both, etc.

dave14:05:58

acid.nvim does just show the eval result inline. you have to open up an "output buffer" if you want to see STDOUT

dave14:05:06

(IIRC)

dave14:05:47

when the eval result is super long, it flows off the screen and you just can't see the full value

Olical14:05:58

Ah okay, was wondering what they did there

Olical14:05:18

Because I could probably format it to 80 cols and split it across a bunch of lines :thinking_face: I think the rust tooling does this with compiler output

dave14:05:24

> Maybe defaulting to inline with having the full formatted thing a keypress away would be cool though! that's exactly what i want! that would be incredible

Olical14:05:30

But yeah, it's a neat thing I can add standalone

Olical14:05:36

It wouldn't be a breaking change

dave14:05:41

i like how the inline result doesn't take up valuable screen real estate, which is nice when the result is short

dave14:05:54

but of course inspecting big maps is crucial

Olical14:05:57

Yep, 100% agreed. But if there's stdout or something then you still want the log to open

dave14:05:03

yeah, totally

Olical14:05:06

And you want access to the full formatted data for re-eval etc

Olical14:05:12

Evalling your repl results is fun 😄

Olical14:05:21

I get a map back, wrap it in code then eval that.

dave14:05:31

oh, neat. i've never tried something like that

Olical14:05:54

Yeah, it's part of the UX I wanted around Conjure. Everything's just code like a normal buffer. So I'm careful to add anything that isn't a regular buffer

borkdude14:05:32

@rahul080327 has done a nice job of adding Vim docs for clj-kondo, in case anyone is interested in trying it: https://github.com/borkdude/clj-kondo/blob/master/doc/editor-integration.md#vimneovim

👏 8

borkdude14:05:38

</end of shameless plug>

nate15:05:47

@borkdude very cool! thank you for making clj-kondo, it's very useful

❤️ 8

dharrigan15:05:29

nice!

dharrigan15:05:39

I use Joker, so will be interesting to see how this works out too

mynomoto18:05:29

@dharrigan clj-kondo is already better than joker for my user case, I use it all the time and recommend it.

dave18:05:35

Better in what ways? I'm also using joker, and curious what the benefits of adding clj-kondo into the mix are

defndaines19:05:22

And to clarify, if I’m on the latest Ale, then it will pull in Joker and Kondo both, if they are installed?

dave19:05:29

from the setup above, it looks like you can configure it to use both

dave19:05:45

i.e. let g:ale_linters = {'clojure': ['clj-kondo', 'joker']}

defndaines20:05:45

I think my confusion is that I have joker installed but I didn’t explicitly configure ale to use it, it just does. Haven’t tested yet to see if I actually need to include that line or if I get it for free because Ale auto-detects it.

mynomoto22:05:25

clj-kondo has less false positives because it understand code on some libraries. Also the configuration is more granular. There are only 2 features that I use from joker atm that unused bindings and undeclared vars but those cause a lot of false positives when using libraries like plumatic/schema and cats because of macros.

💡 4

mynomoto22:05:02

clj-kondo also checks across namespaces for wrong arities.

💡 4

dave23:05:03

Nice, I'll have to give it a try

2019-05-21

Channels