Re: Suggestion to increase usefulness of TAB key / 'org-cycle' function

[Philipp Kiefer]

I see. Thank you for your very helpful reply!

On 01.05.2023 20:45, Ihor Radchenko wrote:

Philipp Kiefer  writes:


Do I understand you correctly that you mean tab should cycle visibility
in this case?

* headline
some text
CURSOR IS HERE
- a list

Yes, I suggested that in those cases, org-cycle should fold the subtree
point is in, i. e. fold up to the next parent heading above.

To get this, just customize `org-cycle-emulate-tab' to nil.


Hm, for me, TAB does not currently seem to do any indenting anywhere in
an Org file.

It just means that  is not configured to do anything in your Emacs.
By default, the Org's fallback is `org-cycle-emulate-tab' or whatever
global  is bound to.


If people use tab for indentation in Org out of the box when not on
headings (which it has never done for me, I think), my suggestion would
indeed be moot.

 does a lot of staff. Just read through `org-cycle' docstring.

Re: Suggestion to increase usefulness of TAB key / 'org-cycle' function

[Philipp Kiefer]

On 28.04.2023 19:41, Dr. Arne Babenhauserheide wrote:

Philipp Kiefer  writes:

My suggestion was aimed at improving the out-of-the-box experience of (new) Org 
users by extending the usefulness of 'org-cycle' by
folding the subtree at point from anywhere inside it that is not itself a 
parent item rather than doing nothing at all in those positions.
I've used two flavours of dedicated outlining software for many years and both 
have easy shortcuts to fold the current subtree from
any position - it is a frequently used action.

Do I understand you correctly that you mean tab should cycle visibility
in this case?

* headline
some text
CURSOR IS HERE
- a list
Yes, I suggested that in those cases, org-cycle should fold the subtree 
point is in, i. e. fold up to the next parent heading above.

For me tab is useful as it is, because it indents whatever I am writing
right now.

That could be a list-item or a source-block or a verse.

Org is not just for outlining but also for full-blown writing, and that
would be disrupted if tab were to fold the entry away that I’m currently
writing in.


Hm, for me, TAB does not currently seem to do any indenting anywhere in 
an Org file. Have you changed anything from the default configuration? 
Or maybe I did and forgot about it... But I can find any reference to / 
binding for unmodified tab in my init.el. If so, is this indenting 
handled by 'org-cycle' or is the binding of Tab to 'org-cycle' somehow 
selective based on where in an Org file point is positioned?


If people use tab for indentation in Org out of the box when not on 
headings (which it has never done for me, I think), my suggestion would 
indeed be moot.



That said: C-c C-t or M-x outline-hide-body


I tried out this command, but it does not do what I have in mind 
(folding subtrees from a non-parent position, not hiding non-heading text).


If tab really does indent in Org files in the default configuration when 
not on a heading, I'd limit my suggestion to the following:


Make 'org-fold-hide-subtree' and / or 'outline-hide-subtree' work from 
anywhere inside a subtree that is not itself a parent heading - not just 
when positioned on the parent heading of the subtree point is in.


Best,

Philipp

Re: Suggestion to increase usefulness of TAB key / 'org-cycle' function

[Philipp Kiefer]

Thanks, Eric, I am aware of customization options.

My suggestion was aimed at improving the out-of-the-box experience of (new)
Org users by extending the usefulness of 'org-cycle' by folding the subtree
at point from anywhere inside it that is not itself a parent item rather
than doing nothing at all in those positions. I've used two flavours of
dedicated outlining software for many years and both have easy shortcuts to
fold the current subtree from any position - it is a frequently used action.



Fraga, Eric  schrieb am Fr., 28. Apr. 2023, 11:45:

> Hi Philipp,
>
> On Friday, 28 Apr 2023 at 10:49, Philipp Kiefer wrote:
> > Well, it could simplify things a good deal further if, on issuing the
> > command when point is *not* on a parent heading, (non-global)
> > org-cycle would instead fold the subtree that point is in, i. e. do
> > 'outline-up-heading' and 'hide-subtree' on the parent heading.
>
> You could always bind TAB to your own command that does this.  As an
> illustration, I have TAB bound to my own function that invokes
> completion instead unless I'm on an org heading!
>
> --8<---cut here---start->8---
> (defun esf/complete-or-indent ()
>   (interactive)
>   (cond
>;; ((eq 'message-mode major-mode)
>;;  (message-tab))
>((and (eq 'message-mode major-mode)
>  (message-point-in-header-p)
>  (looking-back "^\\(To\\|B?[Cc]c\\): *.*"
> (line-beginning-position)))
> (if (looking-back " ")
> (progn
>   (message "try inserting alias abbrev")
>   (insert (symbol-value (intern-soft (completing-read "Expand
> alias: " mail-abbrevs nil t) mail-abbrevs
>   (progn
> (message "try eudc")
> (eudc-expand-try-all
>((eq 'message-mode major-mode)
> (completion-at-point))
>((org-table-p)
> (org-cycle))
>((looking-back "[ \t\n]")
> (if (eq 'org-mode major-mode)
> (if (looking-back "^\\(\\*+ \\| *|\\)[^\\n]*") ;a heading or
> table line
> (org-cycle)
>   (indent-for-tab-command)
>   )
>   (indent-for-tab-command))
> )
>(t
> ;;(consult-company)
> (completion-at-point)
> )))
> --8<---cut here---end--->8---
>
> You could use a similar (and much simpler) approach to get what you
> want.
>
> HTH,
> eric
>
> --
> : Eric S Fraga, with org release_9.6.4-335-ge065b5 in Emacs 30.0.50

Suggestion to increase usefulness of TAB key / 'org-cycle' function

[Philipp Kiefer]

To quote from the Org Manual:
"Org greatly simplifies the use of outlines by compressing the entire show
and hide functionalities into a single command, org-cycle, which is bound
to the TAB key."

Well, it could simplify things a good deal further if, on issuing the
command when point is *not* on a parent heading, (non-global) org-cycle
would instead fold the subtree that point is in, i. e. do
'outline-up-heading' and 'hide-subtree' on the parent heading. This would
make collapsing subtrees a lot easier and quicker as it could be done from
any non-parent position inside a tree. It is very noticeable when
collapsing multiple adjacent trees in succession.

Currently, hitting TAB when not on a parent heading merely returns an
'EMPTY ENTRY' message - not useful at all. 'Outline-up-heading' (C-c C-u)
has to be called manually each time before hitting TAB to achieve what the
user is most likely attempting to do anyway.

Personally, I doubt this change in behaviour would break much for users,
unless one were to assume that there is a lot of Elisp code out there that
relies on 'org-cycle' doing nothing in such cases, incurring the 'EMPTY
ENTRY' reprimand to boot, rather than first checking whether point is on a
parent heading. I don't see any drawbacks when 'org-cycle' is used
interactively.

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Philipp Kiefer]

Even though it can be toggled via the 'hide' variable? Okay, will do!

On 18.02.2023 11:41, Ihor Radchenko wrote:

Philipp Kiefer  writes:


Please peruse attached to reproduce another glitch that occurs with
(setq org-hide-emphasis-markers t). The screencast illustrates what
happens in the sample file. The glitch (the pointer automatically
dropping to the line below a heading rather than staying at the far
right of the heading) seems to occur only when point is on a line below
the mouse click location (the mouse is clicked in the empty space to the
right of headlines) and it does not seem to happen for headings with
children.

I can reproduce, but I do not think that it is Org's bug.
I recommend you sending this reproducer to Emacs devs (M-x
report-emacs-bug).

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Philipp Kiefer]

Thanks a lot for looking into that, Ihor.

However, I wasn't able to fix the bug here. Very likely, I did not 
"install" the fix correctly as I'm not sure how to go about it - or else 
it's not a complete fix yet.


Here's what I did:

1. Downloaded org-cycle.el and org-fold-core.el via the link you sent
2. Verified those are the correct files (found the changes in the files
   that were highlighted in green on the git page)
3. Copied both files over the ones in my
   c:\Users\PK\Documents\emacs_config\.emacs.d\elpa\org-9.6.1\ folder
4. Restarted Emacs

Yet, the issue still occurs in the sample file I sent you.

Did I do something wrong?

Many thanks!

On 17.02.2023 13:01, Ihor Radchenko wrote:

Philipp Kiefer  writes:


I can reproduce with this minimal init.el using Emacs GNU Emacs 27.2
(build 1, x86_64-w64-mingw32)
   of 2021-03-26 and Org mode version 9.6.1:

Thanks for the reproducer!
It is rather an edge case.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=18a146a9d

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Philipp Kiefer]

Hi Ihor,

Sorry for the delay, but I had to weed out my init.el to make sure none 
of the settings were interfering with the problem I was describing.


Please find attached a sample Org file with the bug description and 
steps to reproduce the issue at the bottom of the file. (Also pasting it 
in here: Collapse all trees, then start at the bottommost heading, and 
use ^c^p repeatedly to go up through the headings to the top. Point will 
jump right over Trees 2 and 3 to 1.)


I can reproduce with this minimal init.el using Emacs GNU Emacs 27.2 
(build 1, x86_64-w64-mingw32)

 of 2021-03-26 and Org mode version 9.6.1:

-

(desktop-save-mode 1)
(setq org-hide-emphasis-markers t)
(with-current-buffer " *load*"
  (goto-char (point-max)))

--

I use the last command ("with...") to skip all the rest of my init.el. 
The problem goes away when I set org-hide-emphasis-markers to nil.


A further and likely related issue is that point often jumps to the 
beginning of the next line when I click the mouse to position point at 
the end of a heading. This can not be reproduced in the sample file, I 
think, but I could send you a screencast showing the problem. This issue 
also goes away when setting org-hide-emphasis-markers to nil.


Thanks for looking into this and please let me know if you can reproduce 
or have any further questions.


Best regards,

Philipp

On 26.01.2023 10:15, Ihor Radchenko wrote:

Philipp Kiefer  writes:


...
If any of the conditions listed above are untrue, e. g. I set
'org-hide-emphasis-markers' to nil, or remove the markers from heading A
the problem goes away.

I hope you can reproduce it based on this description.

I would help if you provided an example of the described heading.
* 1
** 1.1
*** 1.1.1
 1.1.1.1
 1.1.1.2
*** 1.2.1
** 1.2
* *2*
** 2.1
*** 2.1.1
*** 2.1.2
** 2.2
* *3*
** 3.1
*** 3.1.1
*** 3.1.2
*** 3.1.3
** 3.2
* 
* Collapse all trees, then start down here, and use ^c^p repeatedly to go up 
through the headings to the top. Point will jump right over Trees 2 and 3 to 1.

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Philipp Kiefer]

On 24.01.2023 18:56, Ihor Radchenko wrote:

Philipp Kiefer  writes:


You set 'invisible text property to nil, which tells Emacs - make the
text visible. Emacs obeys.

Well, with Orgmode version 9.5, Emacs was never *this* obedient, i. e.
this problem only began after I updated Orgmode to 9.6, which is why I
considered it a bug in the first place. I am aware I have set the
keywords to be visible but would not expect them to appear at the end of
the parent heading for a folded subtree! (see the screenshots and the
explanatory .org file). Showing them there does not make any sense in my
opinion. I would expect Orgmode to hide these keywords when they are in
a collapsed subtree, regardless of the 'invisible text' setting, which
is how it was handled pre 9.6 unless I'm much mistaken.

Org may or may not do it, depending on the implementation details.
What you are seeing is because we changed the way Org is folding text to
use text properties instead of overlays (see
https://orgmode.org/Changes.html).

You may get the old behavior back by (1) Setting
`org-fold-core--optimise-for-huge-buffers' to '(grab-invisible); (2)
Setting `org-fold-core-style' to 'overlays before loading Org.

Thank you very much, that fixed it for me.

I do not consider what you report as a bug. There were ways to break Org
folding in the past (for example, by using overlays with high priority).
Actually, I am not sure why you even need to set 'invisible to nil in
your font-lock-keywords.
I chose this option to make it easier to remove emphasis markers but 
have now set up functions to do this for me automatically and have set 
'invisible to true.

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Philipp Kiefer]

On 24.01.2023 12:34, Ihor Radchenko wrote:

Philipp Kiefer  writes:


Org mode version 9.6.1, GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)

Please see the two screenshots here for illustration:

https://imgur.com/a/7EuUi0J  <https://imgur.com/a/7EuUi0J>

(I'm assuming it's not a good idea - or not even possible - to send
e-mail attachments to the list?)

Quite the opposite - attachments are preferred when they do not have
large size. With attachments, the thread can be understood by the
readers years later, when whichever image hosting you use dwindles.


Great, attaching the screenshots in question. Also attaching an .org 
file illustrating the previously reported bug plus another related (and 
more serious as it impedes org functionality) one.




This is the relevant code from my init.el that seems to be causing this
issue:

(require 'org-habit nil t) ; relevant?
(defun org-add-my-extra-fonts ()
    "Add alert and overdue fonts."
    (add-to-list 'org-font-lock-extra-keywords
'("\\(³\\)\\([^\n\r\t]+\\)\\(³\\)" (1 '(face org-habit-alert-face
invisible nil)) (2 'org-habit-alert-face t) (3 '(face
org-habit-alert-face invisible nil))) t)

You set 'invisible text property to nil, which tells Emacs - make the
text visible. Emacs obeys.


Well, with Orgmode version 9.5, Emacs was never *this* obedient, i. e. 
this problem only began after I updated Orgmode to 9.6, which is why I 
considered it a bug in the first place. I am aware I have set the 
keywords to be visible but would not expect them to appear at the end of 
the parent heading for a folded subtree! (see the screenshots and the 
explanatory .org file). Showing them there does not make any sense in my 
opinion. I would expect Orgmode to hide these keywords when they are in 
a collapsed subtree, regardless of the 'invisible text' setting, which 
is how it was handled pre 9.6 unless I'm much mistaken.


The other bug illustrated in the .org file (also requiring specific 
settings, see the init.el section in the file) breaks 
'|org-previous-visible-heading' and probably some other upwards motion 
commands||in connection with parent items having  emphasis markers as 
well as subitems.

|
* 
* Export options: (ignore - but necessary to show problem 1)
#+title: En-GK 12
#+options: ':t *:t -:t ::t <:t H:0 \n:nil ^:nil arch:headline
#+options: author:nil broken-links:nil c:nil creator:nil
#+options: d:(not "LOGBOOK") date:nil e:t email:nil f:nil inline:t num:0
#+options: p:nil pri:nil prop:nil stat:t tags:t tasks:t tex:t
#+options: timestamp:nil title:t toc:nil todo:nil |:nil html-postamble:nil
#+HTML_HEAD_EXTRA: *{font-family: Garamond !important}
#+HTML_HEAD_EXTRA: *{font-size: medium;}
#+EXCLUDE_TAGS: NE
;; [[https://www.w3schools.com/cssref/pr_font_font-size.asp][CSS font-size 
property]]* 
* 
* =problem 1: (repeatedly press C-c C-p starting at the bottom of the file 
until you get up here -> point jumps up towards 'Export options' before it 
reaches this line - or the line below. Seems to be caused by the emphasis used 
on this line plus the fact that this heading has subitems)=
** top child 1
* +top+
** top child 1
* 
* 
* 
* problem 2: the keywords appear at the end of the parent heading when the 
subtree is folded under the parent.
** ³one child with font lock extra keyword³
** @another child with further font lock extra keyword@
* 
* 
* 
* init.el code causing *problem 1*:
(setq org-emphasis-alist   
(quote (
("*" bold)
("/" org-verbatim)
; ("/" italic)
; ("_" underline)
("_" (:strike-through t))
("~" org-code)
; ("~" org-code verbatim)
("=" (:foreground "white" :background "dimgray"))
("+" (:foreground "white" :background "darkslateblue"))
; ("+" (:strike-through t))
)))
* 
* init.el code causing *problem 2*:

(defun org-add-my-extra-fonts ()
  "Add alert and overdue fonts."
  (add-to-list 'org-font-lock-extra-keywords '("\\(³\\)\\([^\n\r\t]+\\)\\(³\\)" 
(1 '(face org-habit-alert-face invisible nil)) (2 'org-habit-alert-face t) (3 
'(face org-habit-alert-face invisible nil))) t)
  (add-to-list 'org-font-lock-extra-keywords '("\\(§\\)\\([^\n\r\t]+\\)\\(§\\)" 
(1 '(face org-habit-overdue-face invisible nil)) (2 'org-habit-overdue-face t) 
(3 '(face org-habit-overdue-face invisible nil))) t)
  (add-to-list 'org-font-lock-extra-keywords '("\\(@\\)\\([^\n\r\t]+\\)\\(@\\)" 
(1 '(face org-habit-clear-face invisible nil)) (2 'org-habit-clear-face t) (3 
'(face org-habit-clear-face invisible nil))) t))
(add-hook 'org-font-lock-set-keywords-hook #'org-add-my-extra-fonts)
* 
* 

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Philipp Kiefer]

On 24.01.2023 04:52, Ruijie Yu wrote:

Philipp Kiefer  writes:


Org mode version 9.6.1, GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)

Please see the two screenshots here for illustration:

https://imgur.com/a/7EuUi0J

(I'm assuming it's not a good idea - or not even possible - to send e-mail 
attachments to the list?)

This is the relevant code from my init.el that seems to be causing this issue:

(require 'org-habit nil t) ; relevant?
(defun org-add-my-extra-fonts ()
   "Add alert and overdue fonts."
   (add-to-list 'org-font-lock-extra-keywords 
'("\\(³\\)\\([^\n\r\t]+\\)\\(³\\)" (1 '(face org-habit-alert-face invisible 
nil)) (2 'org-habit-alert-face t) (3 '(face
org-habit-alert-face invisible nil))) t)
   (add-to-list 'org-font-lock-extra-keywords 
'("\\(§\\)\\([^\n\r\t]+\\)\\(§\\)" (1 '(face org-habit-overdue-face invisible 
nil)) (2 'org-habit-overdue-face t) (3
'(face org-habit-overdue-face invisible nil))) t)
   (add-to-list 'org-font-lock-extra-keywords 
'("\\(@\\)\\([^\n\r\t]+\\)\\(@\\)" (1 '(face org-habit-clear-face invisible 
nil)) (2 'org-habit-clear-face t) (3 '(face
org-habit-clear-face invisible nil))) t))
(add-hook 'org-font-lock-set-keywords-hook #'org-add-my-extra-fonts)

Can you reproduce it?

Thanks!

I am in a region where imgur is unavailable -- can you attach a minimal
org file where the issue manifests, and briefly describe what happens
and should happen?

Sorry, will attach such an org file in my reply to Ihor later.

Also, while looking into your init code, I noticed that
`org-font-lock-extra-keywords' seems to be public-facing (as there is no
double-dashes in the name), but has no docstring.  Either this variable
was intended to be private, or someone forgot to put a docstring to this
variable.


Thanks for making me realize that much of what is in my init.el is miles 
from 'best practice'. At the time I cobbled it together, I was just 
happy when things eventually worked the way I wanted them to and did not 
bother overmuch with proper procedure. No surprise then that it is 
coming back to bite me.


Will put in a 'defvar' statement with a docstring and rename all my 
private functions from 'org-xxx' to 'org--xxx'.

[Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Philipp Kiefer]

Org mode version 9.6.1, GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)

Please see the two screenshots here for illustration:

https://imgur.com/a/7EuUi0J 

(I'm assuming it's not a good idea - or not even possible - to send 
e-mail attachments to the list?)


This is the relevant code from my init.el that seems to be causing this 
issue:


(require 'org-habit nil t) ; relevant?
(defun org-add-my-extra-fonts ()
  "Add alert and overdue fonts."
  (add-to-list 'org-font-lock-extra-keywords 
'("\\(³\\)\\([^\n\r\t]+\\)\\(³\\)" (1 '(face org-habit-alert-face 
invisible nil)) (2 'org-habit-alert-face t) (3 '(face 
org-habit-alert-face invisible nil))) t)
  (add-to-list 'org-font-lock-extra-keywords 
'("\\(§\\)\\([^\n\r\t]+\\)\\(§\\)" (1 '(face org-habit-overdue-face 
invisible nil)) (2 'org-habit-overdue-face t) (3 '(face 
org-habit-overdue-face invisible nil))) t)
  (add-to-list 'org-font-lock-extra-keywords 
'("\\(@\\)\\([^\n\r\t]+\\)\\(@\\)" (1 '(face org-habit-clear-face 
invisible nil)) (2 'org-habit-clear-face t) (3 '(face 
org-habit-clear-face invisible nil))) t))

(add-hook 'org-font-lock-set-keywords-hook #'org-add-my-extra-fonts)

Can you reproduce it?

Thanks!

Re: [FR] Add C-u and C-u C-u prefix arguments to org-paste-subtree (was: Make org-paste-subtree more predictable and useful)

[Philipp Kiefer]

On 20.01.2023 11:21, Ihor Radchenko wrote:

Philipp Kiefer  writes:


Further, you suggest I use C-S- to demote the subtree after
pasting it at the same level as the subtree at point. But what if I used
a numerical prefix argument to copy or cut several subtrees, maybe 5 or
10? Not very convenient at all to demote them all by hand...

I still hold that pasting headings / subtress either at the same level
or at the child level of the target heading is part of the bread and
butter of outline editing and should be as straightforward as possible.
I'm rather sure the current numeric prefixes of org-paste-subtree to
select a distinct level at which to paste are needed / used much less
frequently than a "paste at child level" prefix (maybe C-u C-u?) would
be if it was implemented.

Could you please provide concrete ideas what C-u/C-u C-u should do?
In particular, how it will interact with point located at heading,
at heading beginning, at empty heading, or inside a heading section.
To be honest, I don't see much need for fine-grained special cases. I'd 
be very happy with C-u yanking at the level of the heading at point and 
C-u C-u yanking at one level below that, regardless of the exact 
position of point. I realize that would mean C-u doubling what can 
already be done by calling org-paste-subtree with point at the beginning 
of a heading but accessing both options (paste as sibling or child) with 
a single or repeat C-u seems more consistent to me than having one 
depend on position and getting at the other via the command prefix.


Thanks a lot for your dedication in working on this!

[FEATURE REQUEST] Make org-copy-subtree and org-cut-subtree work on an active region

[Philipp Kiefer]

When calling either org-copy-subtree or org-cut-subtree, check if there 
is an active region that starts on a headline and contains at least one 
more headline of the same level. If so, copy / cut all the subtrees 
touched by the region. This saves the user having to count the subtrees 
he / she wants to operate on in order to use the number as a prefix 
argument for the command. This change  would make the process easier and 
provide visual feedback.


Optionally require that the active region fully encloses two or more 
headlines and nothing else, i. e. that it begins at the start of one 
headline and terminates at the end of another headline.


Thanks.

Re: Make org-paste-subtree more predictable and useful

[Philipp Kiefer]

I've uploaded two screencasts to illustrate the issues described in my 
last message:


1. Org Mode-paste subtree low-level item swallowed: 
https://imgur.com/a/CZ5lDaH . This relates to what I assume the passage 
from the manual is trying to say should not happen:


"makes sure that the subtree
remains an independent subtree and does not swallow low level entries."

2. Org Mode-paste subtree on empty heading glitch: 
https://imgur.com/a/AT5pDj6 . See my last message.


Further, you suggest I use C-S- to demote the subtree after 
pasting it at the same level as the subtree at point. But what if I used 
a numerical prefix argument to copy or cut several subtrees, maybe 5 or 
10? Not very convenient at all to demote them all by hand...


I still hold that pasting headings / subtress either at the same level 
or at the child level of the target heading is part of the bread and 
butter of outline editing and should be as straightforward as possible. 
I'm rather sure the current numeric prefixes of org-paste-subtree to 
select a distinct level at which to paste are needed / used much less 
frequently than a "paste at child level" prefix (maybe C-u C-u?) would 
be if it was implemented.


Best

Philipp


On 19.01.2023 10:44, Ihor Radchenko wrote:

Philipp Kiefer  writes:


Thanks for addressing my concern, Ihor.

So I can force same-level yank by navigating to the beginning of the
current headline before calling org-paste-subtree, I see. However, I
still do not see a way to force it to paste one level below the current
headline, i. e. to add the trees on the clipboard as child-subtrees or
the current heading.

My best bet currently is probably to create a blank child heading, add
some text (there seems to be a glitch turning the blank heading into an
empty line when pasting with point on the blank dummy heading when it
has no text), go back to the beginning of the line, then paste the
subtrees at the level of the dummy heading, navigate back to the dummy
heading and delete it. I'd really rather not have to do all that to
achieve my simple goal of pasting subtrees at child level.

Just paste the subtree and press C-S- to demote it immediately.
It would not save you many keystrokes if there was yet another prefix
argument.


As for the claim that the current procedure "makes sure that the subtree
remains an independent subtree and does not swallow low level entries.",
either I don't understand it or it isn't true. If I have a level 2
heading below which is a level 5 heading and I paste subtrees with point
on the level 2 heading, the level 5 heading is subsumed under the last
subtree yanked from the clipboard in all cases.

Sorry, but I cannot reproduce.
Could you please provide detailed instructions about what you did?

Re: Make org-paste-subtree more predictable and useful

[Philipp Kiefer]

Thanks for addressing my concern, Ihor.

So I can force same-level yank by navigating to the beginning of the 
current headline before calling org-paste-subtree, I see. However, I 
still do not see a way to force it to paste one level below the current 
headline, i. e. to add the trees on the clipboard as child-subtrees or 
the current heading.


My best bet currently is probably to create a blank child heading, add 
some text (there seems to be a glitch turning the blank heading into an 
empty line when pasting with point on the blank dummy heading when it 
has no text), go back to the beginning of the line, then paste the 
subtrees at the level of the dummy heading, navigate back to the dummy 
heading and delete it. I'd really rather not have to do all that to 
achieve my simple goal of pasting subtrees at child level.


As for the claim that the current procedure "makes sure that the subtree 
remains an independent subtree and does not swallow low level entries.", 
either I don't understand it or it isn't true. If I have a level 2 
heading below which is a level 5 heading and I paste subtrees with point 
on the level 2 heading, the level 5 heading is subsumed under the last 
subtree yanked from the clipboard in all cases.


Best,

Philipp

On 18.01.2023 09:04, Ihor Radchenko wrote:

Philipp Kiefer  writes:


Unfortunately, org-paste-subtree currently attempts to "modify the level of
the subtree to make sure the tree fits in nicely at the yank position"
[from Org Manual].
...
My suggestion would be to make a fundamental change to how the command
works, prioritizing definite A) or B) type results over the current vague
"the tree fits in nicely" approach. IMHO the default should be to yank at
the same level as the focused heading. Then, if the C-u 0 numeric prefix
(which currently produces an error message) were used to yank at one level
below that (as subheadings of the focused heading), the functionality of
the other numeric prefixes to set the yank level could be preserved.

AFAIU, `org-paste-subtree' already does what you want for the most part.
See the function docstring:

 Paste the clipboard as a subtree, with modification of headline level.
 
 The entire subtree is promoted or demoted in order to match a new headline

 level.
 
 If the cursor is at the beginning of a headline, the same level as

 that headline is used to paste the tree.
 
 If not, the new level is derived from the *visible* headings

 before and after the insertion point, and taken to be the inferior headline
 level of the two.  So if the previous visible heading is level 3 and the
 next is level 4 (or vice versa), level 4 will be used for insertion.
 This makes sure that the subtree remains an independent subtree and does
 not swallow low level entries.

Make org-paste-subtree more predictable and useful

[Philipp Kiefer]

Hello there, orgmode list, this is my first contribution here, so please be
gentle with me.

I've now used outlining software for the last twenty years at least and it
is my belief that when a user pastes headlines into an outline, they
usually want to make them either A) siblings of (i. e. paste them at the
same level as) or B) children of (i. e. paste them one level below) the
currently focused heading.

Unfortunately, org-paste-subtree currently attempts to "modify the level of
the subtree to make sure the tree fits in nicely at the yank position"
[from Org Manual]. For me, this has meant unpredictable results. As far as
I know, there is currently no way to use the command while making sure the
result will be A) or B) as desired. The user has to wait for the command to
do its "magic" and then move the headings around manually to achieve the
intended result.
With a numeric prefix argument or by yanking after a headline marker, the
user can specify the yank level. But how likely is it that a user will yank
headings to level five under a level two heading?

I can solve my problem with some additional code, in which I determine the
level of the heading at point and then have two functions to call for same
level or child level respectively, but it strikes me as odd that this is
not part of the default options.

My suggestion would be to make a fundamental change to how the command
works, prioritizing definite A) or B) type results over the current vague
"the tree fits in nicely" approach. IMHO the default should be to yank at
the same level as the focused heading. Then, if the C-u 0 numeric prefix
(which currently produces an error message) were used to yank at one level
below that (as subheadings of the focused heading), the functionality of
the other numeric prefixes to set the yank level could be preserved.

Thanks for considering!

Best regards,

Philipp