Re: [O] patch to keep the level in refile

[Nicolas Goaziou]

Sebastian Fischmeister  writes:

>>> This causes problems, when the level has semantic meaning beyond
>>> defining the hierarchy (e.g., level 3 always indicates a task while
>>> levels 2 and 1 are project headings).
>>
>> Why don't you simply refile into the parent, then?
>
> Because there might not be a lvl 2 heading, but still lvl 3 are tasks.

Good point.

Forcing the level of the heading is not a good idea, because it can
badly alter the structure of the document (e.g., you are refiling under
"A", but the task ends up being a grandson).

Maybe we need a more general mechanism to refile "at" instead of
refiling "within", i.e., a mechanism to refile just before a given
headline, at its very same level, which could be a toggle when calling
org-refile.

Maybe this is overkill, tho.

Regards,

[O] patch to keep the level in refile

[Sebastian Fischmeister]

Hi,

This allows to specify via a variable whether org-refile should keep the
level of the item when refiling. At the moment, org-refile automatically
creates a sub-item at the next level. This causes problems, when the
level has semantic meaning beyond defining the hierarchy (e.g., level 3
always indicates a task while levels 2 and 1 are project headings).

Maybe it would be better to have this as a parameter to org-refile, but
I'm just looking for feedback and suggestions right now.

  Sebastian


diff --git a/lisp/org.el b/lisp/org.el
index 6218a3a..8657be8 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -1296,6 +1296,11 @@ commands in the Help buffer using the `?' speed command."
(function)
(sexp))
 
+(defcustom org-refile-keep-level t
+  "Non-nil means entering Org-mode will set keep the level under `org-refile'."
+  :group 'org-structure
+  :type 'boolean)
+
 (defcustom org-bookmark-names-plist
   '(:last-capture "org-capture-last-stored"
  :last-refile "org-refile-last-stored"
@@ -11867,6 +11872,7 @@ prefix argument (`C-u C-u C-u C-c C-w')."
   (region-end (and regionp (region-end)))
   (filename (buffer-file-name (buffer-base-buffer cbuf)))
   (org-refile-keep (if (equal arg 3) t org-refile-keep))
+  (curlevel (funcall outline-level))
   pos it nbuf file re level reversed)
   (setq last-command nil)
   (when regionp
@@ -11959,6 +11965,8 @@ prefix argument (`C-u C-u C-u C-c C-w')."
  (goto-char (point-min))
  (or (outline-next-heading) (goto-char (point-max)
  (if (not (bolp)) (newline))
+ (when org-refile-keep-level
+(setq level curlevel))
  (org-paste-subtree level nil nil t)
  (when org-log-refile
(org-add-log-setup 'refile nil nil 'findpos org-log-refile)

Re: [O] patch to keep the level in refile

[Nicolas Goaziou]

Hello,

Sebastian Fischmeister  writes:

> This allows to specify via a variable whether org-refile should keep the
> level of the item when refiling. At the moment, org-refile automatically
> creates a sub-item at the next level. This causes problems, when the
> level has semantic meaning beyond defining the hierarchy (e.g., level 3
> always indicates a task while levels 2 and 1 are project headings).

Why don't you simply refile into the parent, then?

Regards,

-- 
Nicolas Goaziou

Re: [O] patch to keep the level in refile

[Sebastian Fischmeister]

>> This causes problems, when the level has semantic meaning beyond
>> defining the hierarchy (e.g., level 3 always indicates a task while
>> levels 2 and 1 are project headings).
>
> Why don't you simply refile into the parent, then?

Because there might not be a lvl 2 heading, but still lvl 3 are tasks.

 Sebastian