Fork me on GitHub
#vim
<
2022-01-04
>
markx01:01:37

Neovim doesn't understand chars like \(, \[, \{ correctly. For example, with code (prn \( ), vim would think the \( and the last ) are a pair, so if you press % on them, you jump to the wrong parens. What controls the matching logic for this? Any good way to fix it?

Olical10:01:17

You may want to look into tree-sitter, that should fully understand it. It's a bit of a hoop-jumping exercise at the moment, UX could definitely improve to be more "just work out of the box" but it's still not too bad with some research.

Olical10:01:12

Although if you're talking about % specifically I think that's the matchpairpos or matchpair functions under the hood. Those will walk outwards from the cursor until they find a matching character... so they're not very smart.

Olical10:01:59

I'm not sure if you could improve this really, maybe you could override % with your own call to matchpair (I think that's the name?) that takes into account \ before the current character and skips it. I can't write all of this out, soryy, it'll take some work and I need to get back to my work. I can tell you that the matching fn takes a "skip" function that is checked on each matching character. So you can add extra skipping logic there involving escapes.

Olical10:01:06

Or maybe there's config I'm not aware of 😅

markx02:01:16

OK. it seems that the problem is from Treesitter. After disabling TS highlight, the matching works correct.

Olical10:01:02

Ah okay! That's annoying. TS does seem great but I turned it off too due to performance issues and weird edge cases like this. Maybe one day it'll be ready for the prime time on my machine 🙂

noisesmith17:01:57

this is false with my version of nvim and the clojure syntax file (that is, it understands \( etc. correctly and % does the right thing in your example)

mx200009:01:34

Hi I recently installed vim-fireplace and want to connect to an nrepl-server and evaluate code with ‘cpe’ (current word) Which throws an error

Exception in thread "nREPL-worker-4" java.lang.reflect.InaccessibleObjectException: Unable to make field protected java.io.Reader  accessible: module java.base does not "opens " to unnamed module @2eb231a6
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
	at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:177)
	at java.base/java.lang.reflect.Field.setAccessible(Field.java:171)
	at nrepl.middleware.interruptible_eval$set_line_BANG_.invoke(interruptible_eval.clj:33)
	at nrepl.middleware.interruptible_eval$source_logging_pushback_reader.invoke(interruptible_eval.clj:50)
	at nrepl.middleware.interruptible_eval$evaluate$fn__742.invoke(interruptible_eval.clj:95)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invokeStatic(core.clj:667)
	at clojure.core$with_bindings_STAR_.invokeStatic(core.clj:1977)
	at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1977)
	at clojure.lang.RestFn.invoke(RestFn.java:425)
	at nrepl.middleware.interruptible_eval$evaluate.invoke(interruptible_eval.clj:84)
	at nrepl.middleware.interruptible_eval$interruptible_eval$fn__787$fn__790.invoke(interruptible_eval.clj:220)
	at nrepl.middleware.interruptible_eval$run_next$fn__782.invoke(interruptible_eval.clj:188)
	at clojure.lang.AFn.run(AFn.java:22)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
	at java.base/java.lang.Thread.run(Thread.java:831)

timo11:01:39

Did you load the namespace's require?

timo11:01:52

and import?

timo11:01:21

ah sorry, saw that you fixed it yourself

mx200009:01:55

I can do :Eval {some-code} and it works fine

mx200009:01:11

:FireplaceConnect also worked fine.

mx200009:01:44

For example I can :Eval some var-name, but if I put the cursor on the word and ‘cpe’ it fails…

mx200010:01:51

Fixed with using openjdk@11.