funcall-interactively: Wrong type argument: number-or-marker-p, nil

[codygman]

I thought this might be an issue witht he org-roam-complete-everywhere function, but I called it with evaluate expression and it returns expected results.

I instrumented and stepped through corfu-complete and I noticed that every time before the error in the title occurs completion-in-region--data is nil.

I then did some more digging and figured out that it's only ever nil if I don't have any files whose prefixes begin with the input.

• "ta" completes with corfu fine because I have a file in my system named "talon", but note it also matches "rattata" which doesn't start with prefix "ta".
• "om" does not complete, because I have no roam org files that start with "om". I added the roam org file "omg" and sure enough I started also getting orderless matches like "Common Lisp"

(defun corfu-complete ()
  "Try to complete current input."
  (interactive)
  (cond
   ;; Proceed with cycling
   (completion-cycling (completion-at-point))
   ;; Continue completion with selected candidate
   ((>= corfu--index 0) (corfu--insert nil))
   ;; Try to complete the current input string
   (t (pcase-let* ((`(,beg ,end ,table ,pred) completion-in-region--data)

I'm using on NixOS and using:

GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo version 1.16.0)

[minad]

Can you please give a more precise reproducible? Which steps do you perform precisely? Which corfu settings?

[codygman]

(unless (file-directory-p "/tmp/roam") (make-directory "/tmp/roam"))

(require 'use-package)

(use-package org-roam
  :init
  (setq org-roam-v2-ack t)
  :custom
  (org-roam-directory "/tmp/roam/")
  (org-roam-completion-everywhere t)
  :config
  (org-roam-setup)
  (org-roam-db-autosync-mode))

(require 'corfu) ;; autoload didn't work?
(use-package corfu
  :custom
  (corfu-auto t)                 ;; Enable auto completion
  :init
  (corfu-global-mode))

(use-package orderless
  :init
  (setq completion-styles '(orderless)
        completion-category-defaults nil
        completion-category-overrides '((file (styles . (partial-completion))))))

(use-package dabbrev
  :init
  (setq completion-cycle-threshold 1)
  (setq tab-always-indent 'complete))

;; M-x org-roam-node-find foo-thing RET
;; M-x org-roam-node-find foo-two-thing RET
;; M-x org-roam-node-find bar-thing RET
;; now from within bar-thing you should be able to get corfu orderless completion

;; if you type "foo" you should (and do see):
;; foo  
;; +-----------+
;; | foo-thing |
;; | bar-thing |
;; +-----------+
  
  
;; if you type "thi" you should see:
;; thi  
;; +-----------+
;; | foo-thing |
;; | bar-thing |
;; +-----------+
;; thi

;; You don't... but... and this is the interesting part
;; You can get it to work *if* you create a file that has
;; the "thi" prefix and it will include the other desired results
;; M-x org-roam-node-find thi-thing RET

;; thi  
;; +-----------+
;; | thi-thing |
;; | foo-thing |
;; | bar-thing |
;; +-----------+

I think this is related to not respecting completion-regexp-list as seen in these issues:

joaotavora/eglot#725

In Emacs version 26.1, the docstring at the end of try-completion says: Additionally to this predicate, ‘completion-regexp-list’ is used to further constrain the set of candidates. To me, this means that try-completion internally takes care of filtering candidates according to completion-regexp-list. However, Eglot doesn't use all-completion. Isn't that the root cause of this issue?

I'm guessing here, but appropriately changing cl-remove-if-not to all-completion after the "all-completion" comment might just fix the issue.

joaotavora/eglot#733

This uses all-completions to enable searching of candidates with completion-regexp-list, which CAPF collection functions are required to do (from elisp/basic completion info):

In addition, to be acceptable, a completion must also match all the regular expressions in ‘completion-regexp-list’. (Unless COLLECTION is a function, in which case that function has to handle ‘completion-regexp-list’ itself.)

It also ensures any predicate passed to the collection function is forwarded to try/test-completion.

[minad]

I see. The issue is actually a bug in completion--capf-wrapper. I just looked at this again and pushed a hack, which replaces this capf wrapper with a version which actually works correctly if corfu/completion-styles are used. See c42760f. This should fix the problem. But I still don't understand why you see "Wrong type argument" errors and this confused me in your initial bug report. Your second description of the bug is much clearer. I close this issue since the problem you described should be fixed. Please let me know if there are further problems.

[codygman]

This worked for me, thanks so much for the quick help! ❤️

From my notes it seems that my wrong type argument error was from completion-in-region--data being nil from:

(defun completion--in-region (start end collection &optional predicate)
  "Default function to use for `completion-in-region-function'.
Its arguments and return value are as specified for `completion-in-region'.
Also respects the obsolete wrapper hook `completion-in-region-functions'.
\(See `with-wrapper-hook' for details about wrapper hooks.)"
  (subr--with-wrapper-hook-no-warnings
      ;; FIXME: Maybe we should use this hook to provide a "display
      ;; completions" operation as well.
      completion-in-region-functions (start end collection predicate)
    (let ((minibuffer-completion-table collection)
          (minibuffer-completion-predicate predicate))
      ;; HACK: if the text we are completing is already in a field, we
      ;; want the completion field to take priority (e.g. Bug#6830).
      (when completion-in-region-mode-predicate
        (setq completion-in-region--data
	      `(,(if (markerp start) start (copy-marker start))
                ,(copy-marker end t) ,collection ,predicate))
        (completion-in-region-mode 1))
      (completion--in-region-1 start end))))

But with this fix it's never nil.

I'm not a hundred percent confident in this explanation, but it's the last thought I had on this topic.