Switch from (setf (get-default ...)) to hooks

[Ambrevar]

Hooks could effectively supersede the setf-ability of get-default.
The latter has multiple issues:

• Restarting Next from the REPL does not reset the slot default values.
• If the user appends to default slot values in init.lisp, every restart from the REPL will stack more of the same values.
• Changes are irreversible. If A sets a default and B too, we lose information.
• It's not compatible with all compilers, e.g. CCL. Ultimately it would be nice to have CCL/ECL support.

[vindarel]

Those are usability problems indeed. My guts tell me we'd rather do it in pure CL though.

[Ambrevar]

What do you mean "pure CL"?

[vindarel]

With standard CL mechanism, thus without the hooks library.

[Ambrevar]

How though? I think we can only to it with `initialize-instance :after`, but this can be defined only _once_. Say we already use the :after in the Next code base, then the user won't be able to reuse it (without breaking Next). I believe hooks solve this precise problem (among other things) by exposing a _list_ of handlers. Am I missing something?

[easbarba]

Cant say about hooks, but that syntax is rather verbose, would be interesting a simpler interface to accessors as

(with 'minibuffer (setf minibuffer-font-size "1em"
                              minibuffer-style '((body ...))))

As in Python context-manager.

[Ambrevar]

What you propose is not possible as is, because we don't want to expose global variables. We need new functions, something like ``` (set-interface-default 'minibuffer-style "1em") ``` which would add a handler to the `after-init-hook`. Similarly, we can add helper functions to set values for all running instances of a class, e.g. ``` (set-all-buffers 'scroll-distance 20) (push-all-buffers 'modes 'vi-normal-mode) ``` Thoughts?

[easbarba]

That's even better.

[Ambrevar]

What do you mean? Emacs' setq does not deal with classes.

[Ambrevar]

I thought a little bit about this and I realized a big issue with hooks: if they are not named, the user essentially loses control over what's in it. Lambda are hard to introspect (you can disassemble them...) plus they cannot be compared, which means that adding the same lambda twice to the hook will effectively run it twice.

We could write macros to automatically name the functions, but automatic names don't really help telling what's inside the function, so we've got the same introspection problem.

So here is my suggest: in their init.lisp, the user writes their own functions in which they configure all the slots they want.
Then they write a function that adds the handlers to the write hooks.
Then they add this last function to *after-init-hook*.

Example:

(defun my-minibuffer-defaults (minibuffer)
  (setf
   (minibuffer-line-height minibuffer) "1.1em"
   (minibuffer-font-size minibuffer) "1.1em"))

(defun my-interface-defaults ()
  (push (search-engines *interface*) "https://foo.org...")
  (hooks:add-hook (hooks:object-hook *interface* 'minibuffer-make-hook)
                  #'my-minibuffer-defaults))

(hooks:add-hook '*after-init-hook* #'my-interface-defaults)

Pros:

• It's concise.
• We keep full control, we can introspect everything.
• Changes are reversible, it's easy to delete any handler.
• Handlers are not duplicated when reloading init.lisp.
• No need for convoluted macros.
• No global variables.
• No generate functions.

Cons:

• This is a rather unconventional (very "functional programming" style) approach to configuring a program. But with the right documentation and the right examples, this could be The Right Thing©. Thoughts? @vindarel @jmercouris ?

[Ambrevar]

Also see scymtym/architecture.hooks#2 (comment)

[vindarel]

Is it required that the first add-hook be inside my-interface-default ?

[Ambrevar]

You mean the configuration of minibuffer-hook? Yes, because the hook only exists once *interface* is instantiated.

[Ambrevar]

Closing this in favor of #419.