emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Michael Heerdegen <michael_heerdegen@web.de>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: emacs-orgmode@gnu.org
Subject: Re: How to handle both minor mode and major mode remapping a command?
Date: Sun, 22 Dec 2024 23:08:13 +0100	[thread overview]
Message-ID: <87a5cngylu.fsf@web.de> (raw)
In-Reply-To: <87v7vd5jpz.fsf@localhost> (Ihor Radchenko's message of "Sat, 21 Dec 2024 12:00:40 +0000")

Ihor Radchenko <yantar92@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.


      reply	other threads:[~2024-12-22 22:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-18 11:53 Bug: org-kill-line shouldn't assume visual-line-mode means kill-visual-line Nathan Collins
2024-12-15 10:48 ` How to handle both minor mode and major mode remapping a command? (was: Bug: org-kill-line shouldn't assume visual-line-mode means kill-visual-line) Ihor Radchenko
2024-12-17 17:33   ` How to handle both minor mode and major mode remapping a command? Michael Heerdegen
2024-12-19 17:38     ` Ihor Radchenko
2024-12-19 19:36       ` Michael Heerdegen
2024-12-21 12:00         ` Ihor Radchenko
2024-12-22 22:08           ` Michael Heerdegen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a5cngylu.fsf@web.de \
    --to=michael_heerdegen@web.de \
    --cc=emacs-orgmode@gnu.org \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).