Suggestion about org-deadsync

[legalnonsense]

I do not feel like a fast learner. I feel like I spend an inordinate amount of time screwing up obvious things. Also don't know if I learn more than I let on. Maybe? I have no basis to estimate my own knowledge of any of this, so default it to assuming it is low. Thank you for this code. I actually found an error in my original code where (nbustlast adjustments) needs to be (split-string (car (nbutlast adjustments)) " "). The horror! I need to study what you did here a bit more though. I am slowly getting into the cl stuff. I tried prism.el. My first reaction was that it seemed like a lot going on, and I generally don't like a lot of syntax highlighting. But the more I used it the more I liked it. It looks great on with my dark theme. I need to tinker with it more. I really like the colorized parenthesis. I also liked the sample I saw that tended to keep everything the same color, which I felt gave more of an indication of depth. Have some thoughts but don't want to share them until I play with it a bit. Thanks again for the help on this and everything else. Work is ramping up for me so I'll likely not be writing much, and plan to spend some downtime learning about lisp interpreters in interpreters and such. Will check out some of those books you recommended and hope to come back ready to try something new.

…

On Sun, Aug 25, 2019 at 6:45 AM alphapapa ***@***.***> wrote: Hi, This package is really coming along! You either learn very quickly or already knew much more than you let on. ;) Here's a quick suggestion. In this function, you call ts-adjust once for every adjustment. I doubt the performance would matter in this package, but in general, that will be slower than calling it one time, because of how it works internally. So here's another way to write it that only calls it once: https://github.com/legalnonsense/org-deadsync/blob/eb1c29fd079f1b38ca763690942b913804cc72eb/org-deadsync.el#L108 (defun org-deadsync--ts-adjust (&rest adjustments) "Wrapper for (ts-adjust) to allow arguments in the form, e.g., \"+3d\"; accepts a list of strings in the form \"[+/-][number][d(ay), m(onth), y(ear)]\"." (let* ((ts (-last-item adjustments)) (adjustments (cl-loop for adj in (nbutlast adjustments) for num = (string-to-number (substring adj 0 -1)) for slot = (pcase-exhaustive (substring adj -1) ("d" 'day) ("m" 'month) ("y" 'year)) append (list slot num)))) (apply #'ts-adjust (append adjustments (list ts))))) By the way, if you're interested, I'd love to get your feedback on this new package: https://github.com/alphapapa/prism.el For me it makes lisp code much easier to read and understand. I tried to make the default settings look decent, but it depends on the theme, and it's very customizeable. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=AKUOBHIENLVDV24TCSMLDZ3QGJPEFA5CNFSM4IPIVMLKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HHHHUBQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKUOBHJNSWVIJN4QJE6MAV3QGJPEFANCNFSM4IPIVMLA> .

[legalnonsense]

I just saw all the other suggestions you made. For some reason your first one only came through my email. Thank you! I will work on these.

[legalnonsense]

With regard to the locked deadline, I had the idea that to ensure that the user does not change a locked deadline that I would make the deadline text itself read-only. If the user tries to change a locked deadline, it prompts to see if they want to unlock it.

The only function that uses the deadline-locked-p function is the toggle-lock function, both of which I think I put there for testing.

I am not sure why I used (end-of-visual-line), nor do I know why I used (org-deadline-get-time) instead of (org-entry-get).

But this gets to the point of something I have been wondering about. If I call (org-entry-get) from anywhere within the heading, it'll tell me there is a deadline, but I have no idea of where to find it. Hence my thought that one needed to ensure they knew where they were in the heading before calling re-search-forward (or backward). Otherwise, how would you know which direction to go?

You can't just re-search-backward to get to a heading, because you could very well be at the first point of the heading, and only the next heading would be picked up. Hence moving the point to the end of the line, then searching backward (in case I was actually at the first point of the heading.. This is the only way I could then to ensure the point was at the beginning of the heading, so I could then search for the DEADLINE: regular expression, knowing that I would find it with re-search-forward.

I know the re-searches are unbounded, but I am relying on knowing that I am in a heading and will therefore hit a "^*+ " backwards, and (if on the top line) I'll hit a DEADLINE forwards.

There's also an underlying issue that org doesn't seem to care what order DEADLINE and SCHEDULED appear in (whichever was set last appears first), so you can't assume where the deadline is on the second line.

I had no idea about the regexp variables. I figured I should be using my own, but was too lazy to fix it all when it occurred to me.

Thank you again for the help. Posting this because I am curious if I am doing something wrong-headed. I was screwing around today changing the appearance of the outline in a more fundamental way than with say, org bullets, and it relies on the method I described above for normalizing point positions in a heading. I realize now I write a function that will simply place the point at the beginning of the heading.

Beyond that, if there is a higher level obviousness that I am missing then that would be great!

[alphapapa]

With regard to the locked deadline, I had the idea that to ensure that the user does not change a locked deadline that I would make the deadline text itself read-only. If the user tries to change a locked deadline, it prompts to see if they want to unlock it.

That's a neat idea.

But this gets to the point of something I have been wondering about. If I call (org-entry-get) from anywhere within the heading, it'll tell me there is a deadline, but I have no idea of where to find it. Hence my thought that one needed to ensure they knew where they were in the heading before calling re-search-forward (or backward). Otherwise, how would you know which direction to go?

You can't just re-search-backward to get to a heading, because you could very well be at the first point of the heading, and only the next heading would be picked up. Hence moving the point to the end of the line, then searching backward (in case I was actually at the first point of the heading.. This is the only way I could then to ensure the point was at the beginning of the heading, so I could then search for the DEADLINE: regular expression, knowing that I would find it with re-search-forward.

Use something like:

(save-excursion
  (outline-back-to-heading)
  (when (re-search-forward org-deadline-time-regexp (line-end-position 2) t)
    do-your-stuff)) 

Ideally your code would be running with point on the heading already, so you could omit the call to outline-back-to-heading. It also solves this issue:

There's also an underlying issue that org doesn't seem to care what order DEADLINE and SCHEDULED appear in (whichever was set last appears first), so you can't assume where the deadline is on the second line.

Because it will leave point after the deadline timestamp.

I realize now I write a function that will simply place the point at the beginning of the heading.

Most such functions you'll need already exist in outline.el and org.el. Helm makes these easy to find.

I was screwing around today changing the appearance of the outline in a more fundamental way than with say, org bullets, and it relies on the method I described above for normalizing point positions in a heading.

You might find this function interesting. It adds outline number overlays to headings. They aren't updated automatically, of course, but sometimes it can be useful. To be more correct, it should probably use a unique property for the overlays it makes, so it can only clear those overlays when it runs again. It almost seems like it should be written to use a recursive function, but on the other hand, while trees are recursive, it's parsing them as plain text, which isn't recursive. Of course, you could use org-narrow-to-subtree and write it recursively, but that would probably be slower. Anyway, it's messy, but it works.

(defun ap/org-outline-numbers ()
    (interactive)
    (save-excursion
      (let* ((positions-levels (progn
                                 (goto-char (point-min))
                                 (when (org-before-first-heading-p)
                                   (outline-next-heading))
                                 (cl-loop while (not (eobp))
                                          collect (cons (point) (org-current-level))
                                          do (outline-next-heading))))
             (tree (cl-loop with current-top-level = 0
                            with current-subtree-numbers
                            with results
                            with previous-level
                            for (position . level) in positions-levels
                            if (= 1 level)
                            do (progn
                                 (setq current-subtree-numbers nil)
                                 (setq previous-level level)
                                 (push (a-list 'heading (save-excursion
                                                          (goto-char position)
                                                          (substring-no-properties
                                                           (org-get-heading t t)))
                                               'position position
                                               'level level
                                               'number (concat (number-to-string (incf current-top-level)) "."))
                                       results))
                            else do (let* ((current-level-number (cond ((<= level previous-level)
                                                                        (incf (map-elt current-subtree-numbers level)))
                                                                       ((> level previous-level)
                                                                        1)))
                                           text-number)
                                      (setq previous-level level)
                                      (map-put current-subtree-numbers level current-level-number)
                                      (setq text-number (cl-loop for lookup from level downto 1
                                                                 for lookedup = (map-elt current-subtree-numbers lookup)
                                                                 if lookedup
                                                                 collect lookedup into result
                                                                 else collect current-top-level into result
                                                                 finally return (s-join "." (mapcar #'number-to-string (nreverse result)))))
                                      (push (a-list 'heading (save-excursion
                                                               (goto-char position)
                                                               (substring-no-properties
                                                                (org-get-heading t t)))
                                                    'position position
                                                    'level level
                                                    'number text-number)
                                            results))
                            finally return (nreverse results))))
        (ov-clear)
        (--each tree
          (let-alist it
            (ov (+ .position (1- .level)) (+ .position .level)
                'display .number))))))

I tried prism.el. My first reaction was that it seemed like a lot going on, and I generally don't like a lot of syntax highlighting. But the more I used it the more I liked it. It looks great on with my dark theme. I need to tinker with it more. I really like the colorized parenthesis. I also liked the sample I saw that tended to keep everything the same color, which I felt gave more of an indication of depth. Have some thoughts but don't want to share them until I play with it a bit.

Thanks, let me know what you think after you've used it some more.

Thanks again for the help on this and everything else. Work is ramping up for me so I'll likely not be writing much, and plan to spend some downtime learning about lisp interpreters in interpreters and such. Will check out some of those books you recommended and hope to come back ready to try something new.

Glad I can help a little.

[legalnonsense]

Changes implemented.