Making sense of `nsymbols:command-symbol-p`

[aadcg]

nsymbols:command-symbol-p is defined in Nyxt, command.lisp:

(sym:define-symbol-type command (function)
  (command-p (ignore-errors (symbol-function sym:%symbol%))))

The following contradicts the expectation that 'identity* would be of type nsymbols:command-symbol:

CL-USER> (asdf:load-system "nyxt/gi-gtk")
NYXT> 
(defvar identity*
  (lambda-command identity* (suggestions)
    "Return the SUGGESTIONS unaltered."
    suggestions))
IDENTITY*
NYXT> (command-p identity*)
T
T
NYXT> (nsymbols:command-symbol-p 'identity*)
NIL
T

CC @aartaka

[aartaka]

No, it does not.

---

It's the Lisp-1 vs. Lisp-* yet again: Symbols have:

• A value binding.
• A function binding.
• A type binding etc., but that does not exactly matter now.

Given that symbols have functions separate from values, symbol-function and symbol-value return absolutely disconnected things. And defun and defvar/defparameter define absolutely different bindings too.

In this particular case, Nyxt commands are functions, not values (thus Nsymbols looking at symbol-function). And identity* is a variable (defvar) holding a command value. The fact that this value is a function object does not change the fact that identity* as a symbol has no function binding (due to not being defun/define-command/(setf fdefinition)-ed).

---

This is a mess, yes. That's why I was doubting the design with buffer-load* and identity* being variables, instead of global commands. Making them global commands would make so much more sense, but would also cause them to be user-reachable, which is quite broken. Thus I've chosen the variable-based implementation.

---

But then, making the argument of buffer-load*/identity* to be &optional would fix the whole thing?

[aadcg]

It's the Lisp-1 vs. Lisp-* yet again

Say no more, it's clear now!