There are many things that need to happen before and after execution of each symex command. Currently, these are accomplished either using advice, or in the body of these functions themselves. Advice is not the most robust way to do it. A better way would be to define a new macro, symex-define-command and another one, symex-define-insertion-command, which would take care of the before/after code in the definition of the macro (compare evil's evil-define-command which serves a similar purpose). Then, defining commands could be done as
(symex-define-command symex-delete (count) ...)
The advantage of doing it this way is that (a) it's easier and less cumbersome than registering advice, and (b) it avoids ad hoc handling of before/after logic in each individual command and allows the logic to be centralized and streamlined, (c) makes it easy for both developers and users to add new commands.
As an example of (b), currently, every "repeatable" (in the sense of Evil's dot operator) command needs to be explicitly registered. Using the new macro, this kind of registration could implicitly occur just by using the macro, without requiring a separate registration step. It would allow us to remove the registration code that currently registers existing Symex commands.
countvajhula
commented
1 year ago
There are many things that need to happen before and after execution of each symex command. Currently, these are accomplished either using advice, or in the body of these functions themselves. Advice is not the most robust way to do it. A better way would be to define a new macro,
symex-define-commandand another one,symex-define-insertion-command, which would take care of the before/after code in the definition of the macro (compare evil'sevil-define-commandwhich serves a similar purpose). Then, defining commands could be done asThe advantage of doing it this way is that (a) it's easier and less cumbersome than registering advice, and (b) it avoids ad hoc handling of before/after logic in each individual command and allows the logic to be centralized and streamlined, (c) makes it easy for both developers and users to add new commands.
As an example of (b), currently, every "repeatable" (in the sense of Evil's dot operator) command needs to be explicitly registered. Using the new macro, this kind of registration could implicitly occur just by using the macro, without requiring a separate registration step. It would allow us to remove the registration code that currently registers existing Symex commands.