From: Ihor Radchenko <yantar92@posteo.net>
To: "Dan Drake" <dan.drake@gmail.com>,
"Rudolf Adamkovič" <rudolf@adamkovic.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: org-cut-subtree should respect org-ctrl-k-protect-subtree
Date: Sun, 01 Sep 2024 16:20:47 +0000 [thread overview]
Message-ID: <87y14bpcps.fsf@localhost> (raw)
In-Reply-To: <CAKqbAeEeXb916n9oQN4Z=H-LJHyuhBmXmHO_jZVAxuEoUn=RUA@mail.gmail.com>
Dan Drake <dan.drake@gmail.com> writes:
> I customized org-ctrl-k-protect subtree so that when point is on a
> headline for an entry with some folded content, ctrl-k asks for
> confirmation first.
>
> However, I also have the "k" speed key set up; to me, doing ctrl-K and
> the "k" speed key are the same, but only ctrl-K respects the "protect
> subtree" variable.
>
> I took at look at the source code, and it seems like a trivial change
> to make these two things act consistently: by default, the "k" speed
> key calls org-cut-subtree. I copied over the "when" snippet from
> org-kill-line (which is what ctrl-K ends up calling), and this seems
> to work as expected:
> ...
> ...
> Could this change be included in org?
I am not sure.
`org-ctrl-k-protect-subtree' is only relevant when `org-special-ctrl-k'
is set to non-nil, which is not the default.
When users set `org-special-ctrl-k', C-k will become context-sensitive -
on normal lines it will kill like, while on headings it will kill the
whole subtree. Some users complained that it may be easy to confuse
killing a line a subtree, especially when the subtree being killed is
folded. That's why we have `org-ctrl-k-protect-subtree' customization -
it is very, very specific. I am not even sure if many users use it in
the way it was designed.
In contrast, "k" and its normal binding C-c C-x C-w are calling
`org-cut-subtree' command which has a _single_ purpose - cut a subtree
at point. So, every time the user invokes the relevant key binding, the
intention is not ambiguous as it might be with C-k.
Except accidentally pressed keys, of course.
AFAIU, what you are struggling with is that you sometimes press "k" by
accident, without aiming to cut the subtree. Is my understanding correct?
Rudolf Adamkovič <rudolf@adamkovic.org> writes:
> I think the logic should be
> extracted into a function,
> and tested on all paths:
> - `org-kill-note-or-show-branches' (`C-c C-k'),
This one does not modify anything in the buffer. What do you want to
protect here?
Rudolf Adamkovič <rudolf@adamkovic.org> writes:
> However, we should then also rename
> `org-ctrl-k-protect-subtree'
> to something more general, like
> `org-protect-subtrees',
> as it applies beyond "ctrl-k".
As you saw, the purpose of this option is very specific now.
I am not sure if it is a good thing to expand its scope.
May you list the editing commands that you think can benefit from an
extra confirmation dialog?
Rudolf Adamkovič <rudolf@adamkovic.org> writes:
> I like that name, but perhaps we should zoom out a bit and look at the
> entire family of the non-idiomatic `org-ctrl-*' variables.
... which are `org-ctrl-k-protect-subtree', `org-ctrl-c-ctrl-c-hook',
and `org-ctrl-c-ctrl-c-final-hook'. What do you want to do with the
latter two?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2024-09-01 16:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 13:10 org-cut-subtree should respect org-ctrl-k-protect-subtree Dan Drake
2024-08-27 14:15 ` Rudolf Adamkovič
2024-08-28 11:46 ` Dan Drake
2024-08-29 10:39 ` Rudolf Adamkovič
2024-09-01 16:20 ` Ihor Radchenko [this message]
2024-09-01 18:49 ` Dan Drake
2024-09-15 12:46 ` Ihor Radchenko
2024-09-17 23:36 ` Dan Drake
2024-10-20 12:46 ` Ihor Radchenko
2024-09-03 23:09 ` Rudolf Adamkovič
2024-09-22 16:35 ` Ihor Radchenko
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y14bpcps.fsf@localhost \
--to=yantar92@posteo.net \
--cc=dan.drake@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=rudolf@adamkovic.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.