c++-mode and eglot '"', ':', '>' and '/' unnecessarily begin completion

[ville-h]

Now that emacs has eglot as an lsp I was trying it out in c++-mode and the '"', ':', '>' and '/' characters unnecessarily begin a completion when there's nothing it could possibly complete to. Is this an lsp problem similar to previously rather than company problem?

How do i prevent this from happening? It's very annoying to dismiss the completion box after typing say '"' starting or closing a string literal.

[dgutov]

If there was a problem that was fixed in lsp-mode and works with the current version of company fine, you switched to eglot and see it again in the exact same circumstances, then it's an easy conclusion that the problem is in eglot now. Especially since both packages work off the same underlying info.

I mean, it could be a bug in here too, but last time it wasn't. To have a presumptive bug in eglot fixed, please file a report against it.

[ville-h]

Is it possibly something to do with how I add company-yasnippet into company-backends?

            (setq-local company-backends
                '(
                     (company-capf company-yasnippet)
                )
            )

using the () around the two is the only way I've been able to get my snippets show up as completions. But this then makes it so that I see completions started unnecessarily for various characters. With out company-yasnippet the situation does not occur.

[dgutov]

Seems like it.

Instead of (company-capf company-yasnippet), try (company-capf :with company-yasnippet).

See C-h f company-yasnippet RET for an explanation.

[ville-h]

With:

    (setq-local company-backends
        '(
             (company-capf :with company-yasnippet)
         )
    )

the company box still pops up after various characters unnecessarily.

[dgutov]

Okay, next question: did you by any chance set company-minimum-prefix-length to 0?

[ville-h]

No. It is at its default 3 in my testing environment and it's 1 in my real environment. Both values exhibit this behaviour.

[dgutov]

BTW, if you try posting answers inside the "write a reply" box, that would continue a particular thread.

[ville-h]

Don't know if it's interesting but either backend individually, just (company-capf) or (company-yasnippet), does not exhibit the behaviour.

[ville-h]

Here's my test_with_packages.el:

(require 'package)


(setq debug-on-error t)
(setq no-byte-compile t)
(setq package-archives
    '(
         ("melpa" . "https://melpa.org/packages/")
         ("gnu" . "https://elpa.gnu.org/packages/")
     )
)
(setq package-user-dir
    (expand-file-name (make-temp-name "__remove_remove_remove_test__") user-emacs-directory)
)
(setq custom-file
    (expand-file-name "automatic_customize.el" package-user-dir)
)


(let*
    (
        (pkg-list
            '(
                 ;; add packages:
                 company
                 yasnippet
             )
        )
    )

    (package-initialize)
    (package-refresh-contents)

    (mapc
        (lambda(pkg)
            (unless (package-installed-p pkg)
                (package-install pkg))
            (require pkg)
        )
        pkg-list
    )

    (add-hook 'c++-mode-hook
        (lambda()
            ;; setup packages:
            (use-package company
                :defer t

                :config
                ;; (setq company-idle-delay 0)
                ;; (setq company-minimum-prefix-length 1)
            )

            (use-package yasnippet
                :defer t

                :config
                (setq yas-snippet-dirs
                    (list
                        (concat (expand-file-name user-emacs-directory) "yasnippet")
                    )
                )
                (yas-reload-all)
            )

            (eglot-ensure)
            (yas-minor-mode 1)
            (company-mode 1)
        )
    )

    (add-hook 'kill-emacs-hook
        (lambda()
            (delete-directory package-user-dir t)
        )
    )
)


;; for some reason something overwrites company-backends so have a command to M-x
(defun xxx()
    (interactive)
    (setq-local company-backends
        '(
             (company-capf company-yasnippet)
             ;; (company-capf :with company-yasnippet)
             ;; (company-capf)
             ;; (company-yasnippet)
             ;; (company-dabbrev company-yasnippet)
             ;; (company-yasnippet company-capf)
         )
    )
)


(provide 'test_with_packages)

Here is my test.cxx:

auto ffffff() -> void {
}


auto main() -> int {
    // on the line below try typing one of: '"', ":", ">", "/"
    
    return 0;
}

run emacs like so:

emacs --quick --load ./test_with_packages.el ./test.cxx

have to M-x the command xxx to set company-backends properly. Also making sure there are some yasnippets defined and loaded for c++-mode.

[joaotavora]

I see, you're using two company backends whereas stock Eglot uses only one while managing your buffers. This is partially to avoid oddities like this.

[dgutov]

I see, you're using two company backends whereas stock Eglot uses only one while managing your buffers. This is partially to avoid oddities like this.

Thank you, very helpful.

Anyway, it does seem like " is a useful trigger character sometimes: for #include " it indeed works and provides immediate recommendations.

[dgutov]

Anyway, looking through the open issues, it looks like this problem has been popping up with small variations over the years time and time again. I think I have a better built-in solution almost ready.

[dgutov]

#1405

Some testing will be welcome, but I'll probably merge it soon-ish anyway.

[ville-h]

Also as a test I tried both (company-dabbrev company-yasnippet) and (company-yasnippet company-capf). Neither exhibits the behaviour.

[dgutov]

and (company-yasnippet company-capf)

This approach would break the "trigger characters" functionality, though.

[ville-h]

There is also now a yasnippet-capf package, but I wasn't able to get it to work if I just set backends to (company-capf). To me the name suggests that could be possible. How ever the author doesn't seem to be using company or willing to provide assistance. Thought I'd throw it in the mix if someone who actually knows how to read and program lisp is able to test it out and see whether it makes a difference in behaviour.

[dgutov]

It doesn't seem like it's implemented with being able to combine multiple completion functions in mind (e.g. using one of the helpers in cape), and the built-in CAPF mechanisms are lacking as well, AFAIK.

That's one of the reasons I'm keeping the "native" Company backends alive.

[ville-h]

If I understand the situation correctly languages have special characters designated as trigger characters that may trigger a completion on their own?

At least in my particular case when using the combination: (company-capf company-yasnippet) none of my snippets begin with or even contain any of the characters which trigger the unnecessary completion box. Some ideas come to mind:

a) if the candidates coming from the yasnippet could be filtered by whatever the triggering input was, it would narrow the list down to 0 matching candidates.

b) if there was syntax when adding company-yasnippet backend that it were to be excluded as a valid backend for completion queries that started because of special trigger character: (company-capf :non-trigger company-yasnippet) or something along those lines.

either one would solve my particular case.

[dgutov]

a) if the candidates coming from the yasnippet could be filtered by whatever the triggering input was, it would narrow the list down to 0 matching candidates.

All in all, you could write a company-transformers element which would look before point and return nil if it sees the " character.

b) if there was syntax when adding company-yasnippet backend that it were to be excluded as a valid backend for completion queries that started because of special trigger character: (company-capf :non-trigger company-yasnippet) or something along those lines.

That is difficult to do with the abstractions we use. I wrote a different solution, linked previously: #1405

We're still working out the details so that the result doesn't break the users of cape, or require breaking changes across all backends, but you can test it out and provide some feedback (AFAICS it's working perfectly fine from the user's POV), and/or just take the patch from the first commit (https://github.com/company-mode/company-mode/commit/dedd9aea9e79e0ea0c15c7f0a295c2251a6980a7.diff), apply it to your local installation and run with it.

[dgutov]

@ville-h Now merged to master, check out the latest build on MELPA.

[ville-h]

After ~5 minutes of testing seems to be working alright. Let's see if I run into anything weird tomorrow whilst programming.

[ville-h]

After a more thorough testing period the reported unnecessary completion popups are gone. Good job and thank you to everyone who made it happen. There are some other instances still left, should I open another discussion topic?

[dgutov]

@ville-h Sure. Or continue in this one, if the circumstances are similar enough.