Using advices for core lookup and completion functions?

Development
#1

Have you thought about using advices extensively to decouple the “close” modules in :completion category ?

The (very) rough idea would be to:

  • make the core function an empty shell like the ;;;###autodef cookies
    ;;;###autoload
(defun doom-project-find-file (_dir)
  "Jump to a file in DIR (searched recursively).
If DIR is not a project, it will be indexed (but not cached)."
  (error "No viable backend has been loaded."))
  • Abuse the :before-until placement in hooks that set up (and remove ?) advices in the code of the module
    (defun doom-ivy-project-find-file (dir)
  "Ivy search through DIR"
  (and (file-directory-p dir)
      (file-readable-p dir)
      (actual-ivy-call dir)) ; This might need to be modified to return :refused-completion when the user just quits to avoid chaining
;; on ivy :config code or hook
(advice-add ’doom-project-find-file :before-until doom-ivy-project-find-file)

This way the code in core gets closer to a simple contract interface; and anyone can fully override the logic in doom/core from their own (selectrum for example) modules, the emacslisp way (“Hey I just read about advising maybe I can use that to replace something now ?”

I don’t know how much work this would imply, nor if (ab)using advices can have a significant impact on performance (I don’t think it should be too bad as doom isn’t byte-compiled anyway ?)

Use tab-bar for Emacs 27.1+ workspace management
#2

I plan to use generics, which should accomplish what you’re suggesting. Using advice for a formal API is a big code smell (it’s more for modifying code you don’t yourself control). The next best thing to generics would be the strategy pattern. In any case, some generalization is certainly needed.

2 Likes