Olical / conjure

Interactive evaluation for Neovim (Clojure, Fennel, Janet, Racket, Hy, MIT Scheme, Guile, Python and more!)
https://conjure.oli.me.uk
The Unlicense
1.72k stars 109 forks source link

Disable ConjureOmnifunc for Janet? #559

Open MaxGyver83 opened 6 months ago

MaxGyver83 commented 6 months ago

When I edit Janet files with conjure installed, the auto-completion behaves strangely: As soon as there is no match left (while typing more characters), I suddenly get a list of all possible completions (expectation: no completions). There is another problem when used with lifepillar/vim-mucomplete:

Refresh completion list when switching through chain · Issue #212 · lifepillar/vim-mucomplete

The documentation says:

g:conjure#completion#fallback |omnifunc| to use if the client isn't returning completions, requires completion#omnifunc to be set to "ConjureOmnifunc". For Janet and Racket, this is the main completion method, for Clojure this kicks in if you don't have an nREPL connection yet. Default: "syntaxcomplete#Complete"

Then I tried using syntaxcomplete#Complete directly by setting omnifunc (interactively in vim) or g:conjure#completion#omnifunc in my ~/.vim/after/ftplugin/janet.vim:

let g:conjure#completion#omnifunc = 'syntaxcomplete#Complete'

And the issue is gone! Conjure should do this by default (for Janet files). Is there any advantage in using ConjureOmnifunc as a wrapper?

Olical commented 6 months ago

So I don't think Conjure is providing any completions for Janet whatsoever, it's just not implemented in the client. Which means that it's falling through to syntaxcomplete which means you're getting the various constants defined in the Janet Vim syntax file provided by Neovim, not Conjure.

Here's a peek at what that omnifunc config value is used for, it's called from the on-filetype callback which is triggered when we enter a supported filetype, in this case, Janet.

  (let [fn-name (config.get-in [:completion :omnifunc])]
    (when fn-name
      (nvim.ex.setlocal (.. "omnifunc=" fn-name))))

So we read that omnifunc value then set the buffer local omnifunc value to that function name. You can read more about syntaxcomplete in :help ft-syntax-omni.

The default omnicomplete fn we use in Conjure (which is probably where your issue is coming from!) is this:

(defn omnifunc [find-start? base]
  (if find-start?
    (let [[row col] (nvim.win_get_cursor 0)
          [line] (nvim.buf_get_lines 0 (a.dec row) row false)]
      (- col
         (a.count (nvim.fn.matchstr
                    (string.sub line 1 col)
                    "\\k\\+$"))))
    (eval.completions-sync base)))

That chain of calls under eval.completions-sync eventually calls through to the following code if the client doesn't support completion.

(-?> (config.get-in [:completion :fallback])
     (nvim.call_function [0 prefix]))

SO, my theory is that when we call syntaxcomplete#Complete inside this nvim.call_function line we end up losing some important context data surrounding the cursor which leads it to just show you ALL possible values it can suggest. When we correctly trigger it through omnicomplete directly (as you're doing with your config change) that data is preserved so the function executes with the correct context.

So this isn't an answer, yet, but it's the investigation and explanation of the issue I think. I'll see if I can fix it now, although I'm on a train to run a half marathon, so my commitment is patchy this weekend 😅

Olical commented 6 months ago

Huh, interestingly we're passing the right text into the completion fn, it just returns ALL results

    (a.println "==="
               prefix
               (a.count (-?> (config.get-in [:completion :fallback])
                             (nvim.call_function [0 prefix]))))
;; => === pri 785
Olical commented 6 months ago

Looking through this omnifunc we're trying to use, it's actually quite stateful between calls (I think?)

https://github.com/vim-scripts/SyntaxComplete/blob/master/plugin/syntaxcomplete.vim

It has a bunch of script local (s:...) variables that it seems to update depending on if you're calling it with the first "find start" flag set to true or not. (yeah, there's a boolean flag that completely changes the behaviour of omnifuncs, it's... interesting)

Which means maybe we have to call it in a certain pattern to get it to behave as expected. I can't find that pattern right now though. Maybe we default Julia's omnifunc to this, but I would like to find the right way to keep the current behaviour because although what you suggest should work in theory, it has tradeoffs and might be tricky to implement.

The logic for configuring omnifuncs is ABOVE the client layer where we get to customise this sort of thing. The clients themselves don't get to decide if their completion fn is called or not. So to change the default behaviour for a client we'd need something bespoke that reaches out of the clear cut concerns the client modules give us.

MaxGyver83 commented 6 months ago

Thank you for looking into it! Good luck with your half marathon!