SOLVED - Trouble with Initial Content in Capture Template

Hi all, I have what I hope is a relatively simple troubleshooting question (cross-posted on the Slack channel as well) about the use of the “Initial Content (%i)” org capture expansion in org-roam-capture.

Desired Behavior
I would like to highlight text, call org-roam-find-file, select the desired template (in the case of below “Test”), and then get a capture buffer to edit that is pre-populated with the selected text. I’ve simplified the below configuration from the full template I’d like to use to minimize factors that might be messing it up.

Currently Observed Behavior
I select the text, call org-roam-find-file, select the “Test” template, and then I get a capture buffer that shows the text that was highlighted the first time I selected text and called this template after a restart of emacs.

Already-Attempted Troubleshooting
So, the first time I try this after restarting emacs, it works as expected, but every time after it re-uses the text that was selected the first time I used the template.

First, I simplified the template as much as possible to make sure no other formatting or expansions were interfering. Then I replaced the “initial content (%i)” expansion with the “head of the kill-ring (%c)” expansion - this works as expected (capture template opens with the last text killed or copied). I’ve tried to see whether it matters if I abort or accept the capture template (it seems not to), whether it matters which buffer I call it from (it seems not to), and whether using another template in between uses of this template makes a difference (it seems not to).

Current Configuration

(setq org-roam-capture-templates
  '(("t" "Test" plain (function org-roam-capture--get-point)
     :file-name "Roam_Notes/%<%Y%m%d%H%M%S>-${slug}"
     :head "#+title: ${title}\n#+roam_alias: \n#+roam_tags: \n\n"
     :unnarrowed t)))

So, does anyone have an idea 1) why the %i is getting stuck on the text selected when I first call the capture template, and more importantly 2) any idea how to change it to behave as expected?

Thanks very much to anyone with thoughts!

There was a discussion on Slack about this 2 days ago. Yes, I also noticed that %i in stopped working with org-ref-protocol. In my case that can be fixed by using ${body} instead of %i because the org-ref-javascript provides the body variable.

I just tried with a normal org-capture template, it seems that “%i” expansion only works when you hightlight a region inside Emacs and call the caputure template from this emacs window. Highlighting text in other Emacs windows or even in a web browser didn’t work in “normal org caputre” either.

I also can’t see a commit in org-roam that should be blamed for this, maybe a recent emacs update did the damage.

1 Like

@rakoenig Interesting, thank you for linking the previous discussion! I looked around here for previous topics, but did not search the slack as thoroughly.

I don’t know if this is related, but I was having another org-related issue yesterday before I started working on the capture template. For some reason, :VISIBILITY: properties were not working correctly, and the only fix I could find for it was to revert to the built-in org version (9.3) instead of using the latest via straight.el (9.4.4). I just tried going back to 9.4.4 and the problem persists.

Unfortunately, my elisp is very rudimentary, so I haven’t been able to get very far looking at the org or org-roam source.

Oh, also, I should have clarified based on what you said: the above-described behavior has been entirely within the same emacs frame - I’ve been highlighting text in a buffer, pressing C-c n f (my keybinding for org-roam-find-file), and getting the results I talked about.

At the suggestion of mshevchuk over on the Slack, I updated my installation of org-roam via straight.el and that seems to have solved the problem! Should have been the first thing I tried. Thanks for your help @rakoenig.

1 Like

Is %i working again or shall we use {body}? Thanks!

Hi Adela,

I am not sure what the most preferred answer, but my current template uses %i and has been working fine after updating org-roam.

Please see below for the template I use that includes %i:

          ("s" "Slip" plain #'org-roam-capture--get-point
           "** Body

** Where From
   :VISIBILITY: folded

** Links
   :VISIBILITY: folded

** Tags
   :VISIBILITY: folded

           :file-name "%(jpr-org-roam-slip-name)-${slug}"; the way you put functions into this keyword is to put a '%' before the opening parenthesis, enclosed within a string
           :head "#+title: ${title}\n#+roam_alias: \n#+roam_tags: \n\n#+PROPERTY: Slip_ID NNNN\n#+PROPERTY: Firstness 50\n#+PROPERTY: DATE %<%Y-%m-%d %H%M>\n\n"
           :unnarrowed t)

If you’re interested in what I was doing with (jpr-org-roam-slip-name) in the file name, check out this post explaining the problem I had and how I solved it.

Thanks for your kind answer. %i does not work for me.

My current working template needs to contain “body” in org-roam-capture-ref-templates:

 ("i" "incremental" plain
         "${body}\n%?" ;; this reads from
        ; "%i%?"
         :empty-lines-before 1
         :file-name "web/${slug}"
         :head "#+title: ${title}\n#+roam_key ${ref}\n#+CREATED: %U\n#+LAST_MODIFIED: %U\n\n"
         :unnarrowed t)))

And the bookmarklet, which is the default, is the one below, where you see that “body” is specified.

javascript:location.href = 'org-protocol://roam-ref?template=i&ref=' + encodeURIComponent(location.href) + '&title=' + encodeURIComponent(document.title) + '&body=' + encodeURIComponent(window.getSelection())