general-define-key macro implementation; no need to require general after compile

[noctuid]

The goal would be to provide a macro that acts mostly as a drop-in replacement for general-define-key but that does as much work as possible at expansion time and does not include any general functions in the expansion (so general could be loaded only during compile time like use-package). Probably this would also be a good candidate for use in other libraries.

Some things could not still be supported. I have to make sure this is actually possible. For example, :definer could not take a variable argument because the macro would need to know the definer to dispatch to at expansion time in order to avoid requiring general after compilation. Builtin definers would of course also need to be rewritten as macros.

A rework is needed anyway. In the process, I could improve a lot of things in the rewrite to remove a lot of the special handling (e.g. :states remains builtin but using the extension facilities, parsing for :non-normal-prefix / :gloal-prefix happens in the evil definer and not in the core definer, etc.).

I still think that it's useful to have general-define-key as a function, so maybe I would move all shared helpers into another file as discussed in #144.

[Luis-Henriquez-Perez]

I am eager for this idea because I noticed that my general bindings consume about 3/4 of my startup times. What kind of syntax are you thinking about? I had been playing around with a doom like syntax myself.

(define-key!
  (:map org-mode-map)
  (:nvi "d" #'some-definition))

;; => expands to

(after! evil
  (evil-define-key '(normal visual insert) org-mode-map "d" #'some-definition))

[noctuid]

I half-rewrote general.el around this time last year, but it will probably be a long time before I have the time to finish it. The syntax of the macro version will be pretty much exactly the same as the current general-define-key, so almost no changes to an init file would be required to remove all overhead from key definitions. You wouldn't even need to load most of general's code (will probably split it into multiple files) during init if you only used general macros and compiled your init

This is somewhat hacky and has some caveats though. The recommendation will be to use the macro as a tool to see what a general-define-key actually does by macro expanding it, and I won't recommend people use it in their init files, but I will be using it in mine. For example, you will not be able to use variables or you will have to ensure that they are defined at expansion time. It will still work if you use a variable that is not defined at compile/expansion time, but it will fall back to expanding to the function general-define-key, so there won't be any time savings.

This way any alternate syntax built on top of general-define-key (e.g. general-def) will also still be usable.