Dispatch command hook

[kchanqvq]

Description

I apologize for the noises made last time as I didn't realize there are other places using dispatch-command in the code base. This version also fixes the uses in describe-key and repeat-mode.

Change command-dispatcher to the buffer local dispatch-command-hook. This makes the slot easier to be used/customized by modes, use cases include:

• per-buffer synchronous command loop
• buffer-local pre/post command hooks
• other custom processing like custom error handling

This PR also does the following:

• bug fix: repeat-mode was broken due to calling last-key on window instead of buffer.
• using hook-based API, users of dispatch-command-hook no longer need to assume the value of command-dispatcher before they modify it (they were assuming the old dispatcher was always #'dispatch-command). Now they just push/pop handlers onto dispatch-command-hook. This makes it easier to correctly recursively call commands that changes command-dispatcher, similar to Emacs' recursive edits.

Checklist:

• Git branch state is mergable.
• Changelog is up to date (via a separate commit).
• New dependencies are accounted for.
• Documentation is up to date.
• Compilation and tests ((asdf:test-system :nyxt/<renderer>))
  • No new compilation warnings.
  • Tests are sufficient.

[kchanqvq]

RFC: maybe the default dispatch-command should be a hardcoded fallback instead of being a handler itself in dispatch-command-hook, so that it is

• always there and not possible to remove
• does not get nhooks related restarts established around it

[aadcg]

bug fix: repeat-mode was broken due to calling last-key on window instead of buffer.

Thanks for the fix. I've pushed commit 2b51ecc and kept you as the author.

---

Regarding the PR in general, it's probably OK but I'm still a bit reluctant towards this shift. Generally speaking, I feel that there are plenty of cases where different parties would argue whether a slot belongs to browser or buffer. Besides this one, think about search-engines.

I can only think of 2 ways around it:

1. Error on the side of specificity (all such slots should belong to buffer), as to ensure maximum customization.
2. If buffer would inherit from browser, then all such slots can belong to browser. They can be accessed by the most-specific class buffer. For instance, command-dispatcher could belong to browser but the get method would look like (command-dispatcher buffer).

---

Still, what's more pressing than discussing where the slot belongs is to eradicate the awful idiom of setting a slot to a function. Those must be refactored to methods as per #3459.