Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable ConjureOmnifunc for Janet? #559

Open
MaxGyver83 opened this issue Feb 21, 2024 · 4 comments
Open

Disable ConjureOmnifunc for Janet? #559

MaxGyver83 opened this issue Feb 21, 2024 · 4 comments
Labels
client-janet enhancement New feature or request

Comments

@MaxGyver83
Copy link

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
Copy link
Owner

Olical commented Feb 24, 2024

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
Copy link
Owner

Olical commented Feb 24, 2024

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
Copy link
Owner

Olical commented Feb 24, 2024

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
Copy link
Author

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

@Olical Olical added enhancement New feature or request client-janet labels Jul 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-janet enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants