1

I have a handful of org-remark highlight-annotations which, before a bug in the code-base got fixed, consistently got displaced by 40 characters when I left and returned to the buffer.

In order for the highlight to make sense, I need to manually adjust org-remark-beg and org-remark-end property values back to their original positions, as shown below.

*** sample note
:PROPERTIES:
:org-remark-beg: 6590 -> 6630
:org-remark-end: 6611 -> 6651
:org-remark-id: 9c8548c9
:org-remark-label: nil
:END:

It is very tedious to do the calculations and make the adjustments manually for each note, especially when there are more than a dozen of these to fix. And you have to readjust the same set of notes over and over again.

Given the power of Emacs, I was just wondering if there is a lispy way of programmatically fixing this problem.


Update:

Did some further research and here's what I've found:

org-property-actions allows us to set and/or compute org property values. we just have to do a search-forward to the region and call that function programmatically, or with C-c C-c.

I get, however this error when I try to do the above:

org-compute-property-at-point: No operator defined for property org-remark-beg

So my follow-up, more specific question would be: how do we define a compute operator for a limited set of property tags? (i.e. not all org-remark-beg etc. need to be adjusted.)

Sati
  • 775
  • 6
  • 21
  • https://emacs.stackexchange.com/tags/elisp/info – Drew Jan 10 '23 at 16:43
  • I don't understand why you have to readjust the same set of notes over and over again. If you fix the values *ONCE* and save the file, isn't that enough? – NickD Jan 10 '23 at 21:25
  • @NickD before we fixed the `org-remark` source code, it happens consistently and repeatedly. So I've at least made the same adjustments twice. This is the third time, after the bug is fixed. – Sati Jan 11 '23 at 00:19
  • But that's the last time, correct? – NickD Jan 11 '23 at 00:33
  • 1
    @NickD After the bug is fixed - assuming the problem has been resolved thoroughly - this time should be the last time. But the same skill or insight can still be used to fix and/or adjust property tags en-masse in the future. – Sati Jan 11 '23 at 00:39

1 Answers1

1

Here's a function that will do the adjustment(s) on a single property of the property drawer of the current headline:

  (defun ndk/org-prop-adjust (prop)
     (let ((val (org-entry-get nil prop)))
       (when val
           (org-entry-put nil prop (number-to-string (+ 40 (string-to-number val)))))))

It uses the Property API to get the value of the property (a string) which it then uses to calculate a new value (the old value as a number plus 40, converted back to a string) which it uses to update the setting in place.

The property is a string that is passed to the function. Since we are interested in two properties,we call the function twice: once for each property:

  (defun ndk/fix ()
    (interactive)
    (mapcar #'ndk/org-prop-adjust '("org-remark-beg" "org-remark-end")))

We map the function above over the two properties we want to fix up.

For convenience, we bind the ndk/fix command to a key (that's why we added the interactive spec: to make it a command, so that we can bind it to a key). C-c z is free in my case (you should check to make sure that that's also the case for you), so we bind it to that:

(define-key org-mode-map (kbd "C-c z") #'ndk/fix)

Then we navigate to each headline that needs fixing and press C-c z on each one to fix it up.

There are probably ways to automate the navigation as well, but there is not enough detail in the question to do that. As an example, let's assume that all the top-level headings in the file that have the tag fixup need fixing up and only those: you can find all those headings by using a search that matches tags and properties. You can use that with the mapping function org-map-entries to apply the above function to the selected headlines:

  (org-map-entries #'ndk/fix "fixup+LEVEL=1" 'file)
NickD
  • 27,023
  • 3
  • 23
  • 42