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

Completion for use-package macro (e.g., within :custom) #1077

Open
leinfink opened this issue Jul 4, 2024 · 3 comments
Open

Completion for use-package macro (e.g., within :custom) #1077

leinfink opened this issue Jul 4, 2024 · 3 comments

Comments

@leinfink
Copy link

leinfink commented Jul 4, 2024

I would like to have completion-at-point for use-package. In particular, it would be great if there was a way to let emacs know that inside :custom, it should expect variables, not functions, even though point might look as if it was in a funcall position. If not easily fixable, could someone guide me in the correct direction to work on this?

#277 apparently tried to do something like this, but it didn't seem to lead anywhere.

@montchr
Copy link

montchr commented Jul 17, 2024

I also would like to have improved completion candidates for use-package. I actually switched away from using use-package primarily for this reason. IMHO, calling the underlying functions and macros (e.g. setopt, add-hook) provide a much better sense of discoverability and even (counterintuitively?) save me time and effort because those completions just work. Clearly I rely a lot on completions to help me figure out what I am trying to do 😅

I guess a lot of the issue is use-package's extensive use of unquoted lists. But still, even if the lists in :custom, for example, were quoted, you would still get completion candidates for any symbol, not just variables. Callables like setopt and keymap-set offer out-of-the-box completion appropriate to the context, and they don't require everything to be contained in extraneous lists like :custom and :bind.

@conao3
Copy link
Contributor

conao3 commented Jul 17, 2024

Since when, I think Emacs assumes that the :custom symbols are functions, not variables, and makes code jumps.
The same issue is happening in leaf and I don't know how to solve this problem.
As a work-around, for example, when there is a use-package like this,

(use-package comint
  :custom
  (comint-buffer-maximum-size 20000 “Increase comint buffer size.”)
  (comint-prompt-read-only t “Make the prompt read only.”))
(use-package comint
  :custom
  (a comint-buffer-maximum-size 20000 “Increase comint buffer size.”))
  (comint-prompt-read-only t “Make the prompt read only.”)))

Change it this way, and for comint-buffer-maximum-size, M-. would allow me to jump properly, but it's too bad work-around.

@yonta
Copy link

yonta commented Aug 3, 2024

The default capf used in elisp-mode, elisp-completion-at-point, filters completion candidates based on context (variables, functions, ...).
The problem is that this filter cannot recognize variables in :custom of use-package.

This is not a complete solution, but I am working around the issue by setting (cape-capf-inside-code #'cape-elisp-symbol) to local variable completion-at-point-function in elisp mode.
I distinguish whether a completion candidate is a function or a variable using icon information provided by nerd-icons-corfu.
If you are using company, you can achieve the same with company-box.

Here is a part of my init.el and screenshot:

(defun my/elisp-mode-init ()
  "Set completion function to cape"
  (setq-local completion-at-point-functions
              (list (cape-capf-inside-code #'cape-elisp-symbol))))
(add-hook 'emacs-lisp-mode-hook #'my/elisp-mode-init)

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants