On Fri, Feb 19, 2021 at 1:10 AM Eli Zaretskii wrote: > I must diverge somewhat here, and express my uneasiness, to say the > least, with the recent-ish fashion of making too many user options > have function values. It makes "M-x set-variable" much less > convenient than it should be, and it makes customizing such options > harder for users who aren't proficient in Lisp. We should limit such > option values to the absolute minimum, IMO. I'd very much prefer to > have simple atomic values (symbols, numbers, or strings) that are then > interpreted by the relevant commands to run the necessary code or call > out to necessary subroutines to do the job. I feel that some of us > think that putting functions with the necessary code directly in the > option's value is somehow "cleaner" or "more elegant". I disagree. > I suspect that I ran into an instance of this recently, where the helpful package (an extension that offers expanded help functions, basically) had trouble in it's helpful-callable function with facemenu-face-menu. I tracked the problem down to a bad interaction in helpful with this code in facemenu.el: (defvar facemenu-face-menu > [...]) > (defalias 'facemenu-face-menu facemenu-face-menu) The problem that I get is: Debugger entered--Lisp error: (wrong-type-argument sequencep t) > mapconcat(identity (t) " ") > s-join(" " (t)) > helpful--signature(facemenu-face-menu) > helpful-update() > helpful-callable(facemenu-face-menu) > funcall-interactively(helpful-callable facemenu-face-menu) > call-interactively(helpful-callable nil nil) > command-execute(helpful-callable) I'm not familiar with the (defalias 'foo foo) idiom, so maybe it should be expected to work, and it's just a bug in helpful. (I reported it to the package maintainers already, with a note that I'd mention it here.) There are a few other instances of in emacs that I found with a quick search, and they also cause similar trouble for helpful. Is this an example of an accidental functional value, as I originally expected, or am I barking up the wrong tree and instead just looking at a parsing bug? (My lisp is largely self taught and started with Scheme, so these parts of elisp are murky to me.) Thanks, ~Chad