Re: org-cut-subtree should respect org-ctrl-k-protect-subtree

[Dan Drake]

"AFAIU, what you are struggling with is that you sometimes press "k" by
accident, without aiming to cut the subtree. Is my understanding correct?"

Yes, that's correct. Sometimes I'd use the speed key accidentally and
cut the subtree.

On Sun, Sep 1, 2024 at 11:19 AM Ihor Radchenko <yantar92@posteo.net> wrote:
>
> 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>



-- 
Ceci n'est pas une .signature.