Fork me on GitHub
#conjure
<
2020-08-27
>
uwo19:08:47

Workflow question here: When I encounter an exception raised by a spec-instrumentation failure, I typically want to immediately look at the ex-data. I know we can print the most recent exception with <leader>ve, however the ex-data is all on one line which, given the size of most spec-data failures, isn't an effective way to view the error. Right now I'm just writing and eval'ing (ex-data *e) in any buffer. Maybe this is really the easiest thing. I'd be happy to hear any other suggestions!

dave20:08:28

eval-ing (ex-data *e) sounds reasonable to me. maybe you could set up a custom mapping, so that you don't have to type it out?

💯 3
Olical20:08:19

Hmm, I've never really hit this but as you say: Workflow. I'd personally end up creating my own mapping to :ConjureEval ... with some code that did what I wanted, but that's maybe a bit of a lazy excuse from me.

Olical20:08:03

You could even extract that data and run it through "explain", right?

Olical20:08:09

Which could be a really nice custom mapping!

Olical20:08:20

(I really want to encourage custom mappings that do exactly what you want)

💯 3
uwo18:08:44

Completely agree with preferring custom-mappings over adding to the conjure built-ins. It could be fun to have a conjure-wiki section of custom-mappings from other people's workflows.

Olical20:08:44

Also, here's a video of a stream I did earlier! Just a little nvim config changes as well as Conjure fixes and improvements https://www.youtube.com/watch?v=SMrN5KQo-eA

💯 12
👏 9
Olical20:08:55

I implemented auto connect on eval! It was harder than I thought!

Olical20:08:10

You can see my struggle and eventually throw out one approach!

👀 3
uwo18:08:44

Completely agree with preferring custom-mappings over adding to the conjure built-ins. It could be fun to have a conjure-wiki section of custom-mappings from other people's workflows.