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

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

[Dan Drake]

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:

(defun org-cut-subtree (&optional n)
  "Cut the current subtree into the clipboard.
With prefix arg N, cut this many sequential subtrees.
This is a short-hand for marking the subtree and then cutting it."
  (interactive "p")
  (when (and (org-invisible-p (line-end-position))
           org-ctrl-k-protect-subtree
           (or (eq org-ctrl-k-protect-subtree 'error)
           (not (y-or-n-p "Kill hidden subtree along with headline? "))))
      (user-error
       (substitute-command-keys
    "`\\[org-kill-line]' aborted as it would kill a hidden subtree")))
  (org-copy-subtree n 'cut))

Could this change be included in org?






-- 
Ceci n'est pas une .signature.

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

[Rudolf Adamkovič]

Dan Drake <dan.drake@gmail.com> writes:

> I took at look at the source code, and it seems like a trivial change
> to make these two things act consistently: [...]

Dan,

Thank you for reporting the bug and even prototyping a solution.

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'),
- `org-cut-subtree' (`k' on first *) and
- `org-kill-line' (`C-k').

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".

Rudy
-- 
"The whole science is nothing more than a refinement of everyday
thinking."  --- Albert Einstein, 1879-1955

Rudolf Adamkovič <rudolf@adamkovic.org> [he/him]
http://adamkovic.org

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

[Dan Drake]

I agree, a function that examines the "protect subtree" variable and
performs the logic is best. I can work on that.

What do you think we should have for the new name for
org-ctrl-k-protect-subtree? Just "org-protect-subtree"?

How do we handle renaming the variable? We'd want some way of
deprecating the old one and so on.


On Tue, Aug 27, 2024 at 9:15 AM Rudolf Adamkovič <rudolf@adamkovic.org> wrote:
>
> Dan Drake <dan.drake@gmail.com> writes:
>
> > I took at look at the source code, and it seems like a trivial change
> > to make these two things act consistently: [...]
>
> Dan,
>
> Thank you for reporting the bug and even prototyping a solution.
>
> 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'),
> - `org-cut-subtree' (`k' on first *) and
> - `org-kill-line' (`C-k').
>
> 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".
>
> Rudy
> --
> "The whole science is nothing more than a refinement of everyday
> thinking."  --- Albert Einstein, 1879-1955
>
> Rudolf Adamkovič <rudolf@adamkovic.org> [he/him]
> http://adamkovic.org



-- 
Ceci n'est pas une .signature.

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

[Rudolf Adamkovič]

Dan Drake <dan.drake@gmail.com> writes:

> What do you think we should have for the new name for
> org-ctrl-k-protect-subtree? Just "org-protect-subtree"?

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.

Most importantly, though, we should wait for Ihor to say his thoughts,
as he is THE expert to consult, especially with regards to the APIs and
overall design of the Org mode.

> How do we handle renaming the variable? We'd want some way of
> deprecating the old one and so on.

Fortunately, Emacs has us covered.  See `defalias'.  Such functions are
used all over the Emacs code base, allowing it to move forward, for
decades to come, in a backward compatible way.

Thank you for making Org better!

Rudy
-- 
"The whole science is nothing more than a refinement of everyday
thinking."  --- Albert Einstein, 1879-1955

Rudolf Adamkovič <rudolf@adamkovic.org> [he/him]
http://adamkovic.org

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

[Ihor Radchenko]

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>

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.

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

[Ihor Radchenko]

Dan Drake <dan.drake@gmail.com> writes:

> "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.

Then, what about introducing something similar to
`org-agenda-archive-default-with-confirmation' -
`org-cut-subtree-with-confirmation' that will query user?
Then, you can bind it to "k" in `org-speed-commands' if it is what you
prefer.

-- 
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>

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

[Dan Drake]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

I like that idea. It's consistent, uses "prior art", so to speak, and most
of all , archiving involves cutting the subtree, so it's a very similar
change to the buffer / structure.

On Sun, Sep 15, 2024, 07:44 Ihor Radchenko <yantar92@posteo.net> wrote:

> Dan Drake <dan.drake@gmail.com> writes:
>
> > "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.
>
> Then, what about introducing something similar to
> `org-agenda-archive-default-with-confirmation' -
> `org-cut-subtree-with-confirmation' that will query user?
> Then, you can bind it to "k" in `org-speed-commands' if it is what you
> prefer.
>
> --
> 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>
>

[-- Attachment #2: Type: text/html, Size: 1798 bytes --]

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

[Rudolf Adamkovič]

Ihor Radchenko <yantar92@posteo.net> writes:

>  > - `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?

Oops!  That was a brain fart.

> 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.

I understand now too.  Thank you for the explanation!

> May you list the editing commands that you think can benefit from an
> extra confirmation dialog?

Me?  I regularly archive subtrees by mistake. :)

> ... 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?

The original idea was: If we are renaming the function, we might
consider looking at the entire family, as naming after key strokes is
not idiomatic in Emacs, nor a good idea, and should be slowly fixed
long-term, IMO.  If we are not renaming anything, the idea can be
ignored, of course.

Rudy
-- 
"Logic is a science of the necessary laws of thought, without which no
employment of the understanding and the reason takes place."
--- Immanuel Kant, 1785

Rudolf Adamkovič <rudolf@adamkovic.org> [he/him]
http://adamkovic.org