Ihor Radchenko <yanta...@posteo.net> writes:
> My main problem with the idea of kill-line-function is that I do not
> fully understand how it can work in all cases. Specifically, imagine
> what happens when visual-line-mode is activated _after_ Org mode is
> activated. How can Org mode make sure that kill-visual-line does not
> unconditionally override Org bindings?
`add-function' wrappers are all combined, and that in a well defined
way. When specifying the 'depth' property in the optional PROPS
argument (using different depths of course), the order (or invocation
times) of `add-function' calls of a place are irrelevant, the resulting
semantics is controlled by the specified depths - for example:
#+begin_src emacs-lisp
(defvar my-f (lambda (x) (* x x)))
(add-function :around my-f
(lambda (o-f x)
(if (< 0 x) 'important (funcall o-f x)))
'((depth . -10) (name . outermost)))
(add-function :filter-return my-f #'1+)
(funcall my-f 2) --> important
#+end_src
A layer at the top has complete control over the behavior of the
function since it can completely discard the code of the inner layers.
It can also do that conditionally and fall back to or use the existing
implementation only in some cases. As you see, this outermost layer is
installed first in the above example.
[ A second dimension of control: Outer layers can bind special
variables around the call of the remaining layers (like (funcall o-f x)
above) to modify the semantics of those inner layers when their
implementation refers to those variables. ]
For my taste this well defined function-only approach is better than
trying to control competing keymaps using different mechanisms (minor
vs. major modes vs. transient maps; key bindings vs. command
remappings).
Michael.
