emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees


From: Leo Vivier
Subject: Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees
Date: Tue, 19 Feb 2019 16:28:28 +0100

Hello again,

Leo Vivier <address@hidden> writes:

> I was pleased to see that property-adding functions didn't behave badly
> with 1-line subtrees.  Maybe we could investigate those commands and
> patch their behaviour onto the problematic ones?
>
> If that sounds good to you, I could work on it and submit another patch.

I’ve investigated the problem, and I’ve stumbled upon something
interesting.

I’ve started by looking at the differences between `org-set-property'
and `org-schedule' which respectively led me to
`org-insert-property-drawer' and `org-add-planing-info'.  The
interesting difference is in the way they handle newline insertion:


`org-insert-property-drawer':
--------------------------------[START]--------------------------------
...
(insert "\n:PROPERTIES:\n:END:")
...
---------------------------------[END]---------------------------------


`org-add-planing-info':
--------------------------------[START]--------------------------------
...                      
(insert-before-markers "\n")                    ; Inside a cond
...
(insert (cl-case what                           ; Inside a later cond
                   (closed org-closed-string)
                   ...
                   )
                 " ")
...
---------------------------------[END]---------------------------------


By adapting the `org-add-planing-info' to insert the newline with the
scheduling information, I could get it to insert its text *inside* the
narrowing with a 1-line subtree.

I'm providing a patch at the end of this email, but it's rough around
the edges.  Notably, I didn't have time to make it work with the
condition tree, which means that re-scheduling as well as adding a
deadline on top of a scheduled time results in spurious newlines.

Correct me if I'm wrong, but I believe we'd be departing the 'hackish'
territory with that solution, which would be great.

Here's the patch:
--------------------------------[START]--------------------------------
Move newline insertion

---
 lisp/org.el | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ef6e40ca9..6c43d9b25 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13046,18 +13046,19 @@ WHAT entry will also be removed."
                    (unless (= (skip-chars-backward " \t" p) 0)
                      (delete-region (point) (line-end-position)))))))
             ((not what) (throw 'exit nil)) ; Nothing to do.
-            (t (insert-before-markers "\n")
-               (backward-char 1)
+            (t (backward-char 1)
                (when org-adapt-indentation
                  (indent-to-column (1+ (org-outline-level))))))
        (when what
         ;; Insert planning keyword.
-        (insert (cl-case what
-                  (closed org-closed-string)
-                  (deadline org-deadline-string)
-                  (scheduled org-scheduled-string)
-                  (otherwise (error "Invalid planning type: %s" what)))
+        (insert "\n"
+                (cl-case what
+                   (closed org-closed-string)
+                   (deadline org-deadline-string)
+                   (scheduled org-scheduled-string)
+                   (otherwise (error "Invalid planning type: %s" what)))
                 " ")
+        (end-of-line)
         ;; Insert associated timestamp.
         (let ((ts (org-insert-time-stamp
                    time
-- 
2.20.1
---------------------------------[END]---------------------------------

HTH.

Best,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



reply via email to

[Prev in Thread] Current Thread [Next in Thread]