Fork me on GitHub
#calva
<
2021-07-31
>
alpox07:07:40

@slawek098 im using neovim for vscode and it alwayw moves through thr whole one. I thought there are vim plugins for that but I didnt try that yet

otwieracz07:07:31

So it definitely works sometimes. In regular vim plugin there is word boundary setting that should stop on -

alpox07:07:03

Are you using vscode vim or neovim?

alpox07:07:50

https://github.com/VSCodeVim/Vim/issues/1090 for vscode-vim there seems to be the vim.iskeyword setting but it sounds weird to me that it sometimes works and sometimes not

otwieracz07:07:04

OK, so I reproduced it. It definitely is related to Calva somehow.

pez08:07:36

I'd say that might be by design, or just an artifact of how vscode allows this to be handled. It's the same if you double-click foo in foo-bar.

alpox08:07:42

Ok... very weird behavior. When any of the two (calva, vscode vim) are disabled, editor reloaded and again enabled it starts working (stopping at -). If calva is never activated it always works. If calva and vscode vim are both active when starting vscode it will not stop at - and jump to the end of the word.

alpox08:07:04

Is it possible that this has to do with the extension load-order?

pez09:07:15

It's entirely possible. There can only be one definition of what is a word and if two extensions compete about it only one will succeed.

alpox09:07:31

I just found out that they have the vim.iskeyword setting in vscode-vim backwards...

otwieracz09:07:57

What do you mean by backwards?

alpox09:07:39

In vim (at least neovim) if you add something to iskeyword it is treated as part of the text (respectively you will jump over it with w) In vscode-vim if you add something to iskeyword the opposite happens. It is treated as word-boundary.

otwieracz09:07:28

I think it’s to keep it consistent with vscode builtin “Word Separators” settings.

alpox09:07:51

It is, but the naming for vim-users is quite off then. I find it also weird that whenever you set vim.iskeyword the editor word separator settings are instantly overwritten instead of just using the precedence. May be that it wasn't otherwise possible to implement. That aside, I sadly could not figure out what in calva could override the word boundaries

pez09:07:04

It could be an honset mistake.

pez09:07:11

In Calva the word pattern is defined like so: "wordPattern": "[^\\s,#()[\\]{}꞉;\"\\\\@]+"

alpox09:07:35

Ah no - in there - that may be the problem :thinking_face: is that configurable?

otwieracz09:07:16

But no - in wordPattern - won’t that mean that - is not part of a word?

pez09:07:13

It’s a negated match ( [^…])

pez09:07:00

And word separators like so:

"editor.wordSeparators": "\t ()\"':,;~@#$%^&{}[]`"
https://calva.io/customizing/#clojure-defaults

pez09:07:28

We can’t change the wordPattern w/o breaking Calva.

Niclas14:07:55

👏 I don't know who to thank so I'm throwing it out here. I just find it truly amazing that I can get code completion in calva on Node dependencies out-of-the-box with shadow 🎉

🎉 7
pez14:07:10

Iirc, that’s a lot @robertkrahn’s doing. And of course @bozhidar. https://github.com/clojure-emacs/clj-suitable

metal 10
Niclas14:07:27

Thanks to you both @robertkrahn and @bozhidar then!

👍 4
alpox17:07:21

Aiie there we go. Works!

alpox17:07:17

@slawek098

"[clojure]": {
    "editor.wordSeparators": "\t ()\"':,;~@#$%^&{}[]`-",
  }
This in the settings and its going smooth with vscode vim. I wanted to send this since right after the discussion at 11:20 but lost internet for the day...

pez17:07:48

Thanks for persisting!

pez17:07:18

Can you add that to the issue? We need to consider if that should be Calva's default.

alpox17:07:50

I will add it as soon as im home (and hopefully remember)

🙏 2