From: Ihor Radchenko <yantar92@posteo.net>
To: Sebastian Miele <iota@whxvd.name>
Cc: emacs-orgmode@gnu.org, 65734@debbugs.gnu.org
Subject: Re: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
Date: Tue, 05 Sep 2023 10:29:20 +0000 [thread overview]
Message-ID: <87tts8vrpb.fsf@localhost> (raw)
In-Reply-To: <87il8pao4l.fsf@whxvd.name>
Sebastian Miele <iota@whxvd.name> writes:
> I first reported this to bug-gnu-emacs@gnu.org (see
> https://debbugs.gnu.org/65734). However, Eli asks:
>
>> I'm not sure I understand why this is deemed a problem in Emacs.
>> Shouldn't Org redefine C-S-<backspace> if the default binding doesn't
>> suit what happens in Org buffers? Did you discuss this with Org
>> developers?
Confirmed.
I am CCing debbugs as I'd like to clarify things to be in sync with
Emacs.
> In an emacs -Q, create an Org buffer with the following contents:
>
> --8<---------------cut here---------------start------------->8---
> * AB
> ** C
> --8<---------------cut here---------------end--------------->8---
This will produce
* AB...
> Fold the subtree under the heading AB, so that only a single line is
> displayed (ending in "..."). With point between A and B, hit
> C-S-<backspace> (kill-whole-line).
>
> Expected: The whole _visible_ line, i.e., the entire contents of the
> buffer is erased. Actual behavior: The line with heading C remains.
This indeed happens because `kill-whole-line' deletes the line in two
steps: "* A" and then the rest.
The first deletion leaves
B<begin invisible>
** C<end invisible>
which drastically alters the outline structure and triggers or to
automatically unfold the subtree, leaving
B
** C
visible.
Then, `kill-whole-line' proceeds with the second part of the deletion
and deletes the now visible line, leading to the observed behaviour.
The first deletion would be an equivalent of deleting "(defun"
(defun foo ()...
in outline-mode and would make it hard to unfold the body, if such
single deletion where performed.
In Org mode, because of frequent user requests about accidental
deletions of hidden text, we try our best to protect deletions of
invisible folded outlines. Automatic unfolding is one of the ways to
attract user's attention to potential accidental edit.
> Contrast this with the same experiment, except that the point is at the
> beginning of the line containing AB when hitting C-S-<backspace>. Then
> the expected behavior happens. According to the source of
> kill-whole-line, the intended effect indeed is to kill a whole _visible_
> line.
Currently, Org mode, similar to Eli's suggestion re-binds `kill-line' to
Org's own version - `org-kill-line'. But not `kill-whole-line'.
We can certainly do the same for `kill-whole-line', but in our previous
discussion https://yhetil.org/emacs-devel/87tu8rq2l6.fsf@localhost/, you
asked to consider extending the built-in Emacs commands instead of
overriding them.
As I described in the above, Org needs more control over the behaviour of
`kill-line'/`kill-whole-line' when the visible line contains multiple
lines of hidden text - to protect accidental deletions.
A hook, where Org can intervene with a yes/no prompt, would be useful.
It would also make sense to group the two edits together via
`combine-after-change-calls', although a more universal way to know that
certain edits are a part of the same known command (even when called
non-interactively) would be useful.
In addition, `org-kill-line' acts specially in certain scenarios:
For
* Heading <point> text :tag1:tag2:
`org-kill-line' will keep and re-align ":tag1:tag2:":
* Heading <point> :tag1:tag2:
It would be nice if we could express such behavior without overriding
the `kill-line' command.
--
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:[~2023-09-05 10:29 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-04 16:30 [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)] Sebastian Miele
2023-09-05 10:29 ` Ihor Radchenko [this message]
2023-09-05 11:54 ` bug#65734: " Eli Zaretskii
2023-09-05 15:25 ` Sebastian Miele
2023-09-05 15:50 ` Eli Zaretskii
2023-09-06 8:23 ` Ihor Radchenko
2023-09-06 12:16 ` Eli Zaretskii
2023-09-06 13:30 ` Sebastian Miele
2023-09-07 13:49 ` Ihor Radchenko
2023-09-06 8:30 ` Ihor Radchenko
2023-09-06 12:20 ` Eli Zaretskii
2023-09-07 10:00 ` Ihor Radchenko
2023-09-07 10:19 ` Eli Zaretskii
2023-09-07 10:27 ` Sebastian Miele
2023-09-07 13:43 ` Ihor Radchenko
2023-09-06 15:04 ` Sebastian Miele
2023-09-07 10:03 ` Ihor Radchenko
2023-09-05 14:30 ` Max Nikulin
2023-09-05 15:42 ` Eli Zaretskii
2023-09-05 15:50 ` Ihor Radchenko
2023-09-05 16:02 ` Max Nikulin
2023-09-05 16:12 ` Ihor Radchenko
2023-09-05 16:14 ` Eli Zaretskii
2024-01-07 16:27 ` Stefan Monnier
2024-01-08 12:15 ` Ihor Radchenko
2024-01-08 15:33 ` Stefan Monnier
2024-01-09 14:52 ` Ihor Radchenko
2024-01-09 16:48 ` Stefan Monnier
2024-01-09 22:21 ` Ihor Radchenko
2024-01-09 15:47 ` Ihor Radchenko
2024-01-09 16:01 ` Stefan Monnier
2024-01-09 22:33 ` Ihor Radchenko
2024-01-10 3:08 ` Stefan Monnier
2024-01-10 12:52 ` Eli Zaretskii
2024-01-10 13:05 ` Ihor Radchenko
2024-01-10 13:55 ` Eli Zaretskii
2024-01-11 15:50 ` Ihor Radchenko
2024-01-11 16:05 ` Eli Zaretskii
2024-01-11 16:15 ` Ihor Radchenko
2024-01-11 16:44 ` Eli Zaretskii
2024-01-11 18:08 ` Ihor Radchenko
2024-01-11 19:19 ` Eli Zaretskii
2024-01-12 12:24 ` Ihor Radchenko
2024-01-12 12:32 ` Eli Zaretskii
2024-01-12 12:39 ` Ihor Radchenko
2024-01-12 14:03 ` Eli Zaretskii
2024-01-12 14:15 ` Ihor Radchenko
2024-01-12 21:09 ` Stefan Monnier
2024-01-12 21:16 ` Ihor Radchenko
2024-01-10 16:26 ` Stefan Monnier
2024-01-10 16:39 ` Eli Zaretskii
2024-01-11 15:44 ` Ihor Radchenko
2024-01-09 15:50 ` 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
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=87tts8vrpb.fsf@localhost \
--to=yantar92@posteo.net \
--cc=65734@debbugs.gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=iota@whxvd.name \
/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).