I’ve been messing with Templater and QuickAdd but cannot find the magic sauce.
Here is what I’ve tried. I guess I’m supposed to tell you what I’m doing later.
That’s a nice quickadd example, with prompting for file-name and fields! Out of personal curiosity, unrelated to your issue: which does it prompt your for first, the file name or the context?
For the sake of narrowing-down the problem, if you use the command palette to insert your templater template to the file produced by quickadd with the filled-in yaml, does the template do its job?
Then comes an unexpected prompt. Where is this coming from? I’m confused because I don’t have it set to apply a template during the capture, and the template piece already has a Template file name to apply… so what gives here?
if I carefully type the correct template name into the field, it gets applied ==twice==. Before anyone asks, I deleted the file before running the macro, and did not run the Template by hand in this second example, just filled out everything as above but entered the Ten.
I don’t know if this helps, but the original screenshot that prompted my original question was because I didn’t enter the template name correctly in the mysterious prompt for that.
If I don’t enter the correct template name there, then on completion, this is what I have. I wanted to mention this because I think it would say something to a knowledgable observer.
Aha, I just looked more closely and realized that the Template was applied to the wrong file! The Template got appended to the Template instead of the new file!
This implies a bug in the Template piece of the Macro maker:
Clearly the “apply meeting template” prompt is definitely coming from the Template piece of the macro, as that’s the title I gave that piece.
It seems to be applying the template to the Template File itself, replacing all its text twice with the frontmatter from the target file, when I answer the “apply meeting template” prompt with the actual Template name.
Nice investigations and thanks for all the really clear screen-shots! Possible workaround: instead of having the second step of your macro be a “template” option, can you use the “obsidian command” box to do the insert template operation you did manually to the half-file? You may have already figured this out, but I just discovered: if you go to the “Templater” settings tab and add your file to the “Template Hotkeys” list, even if you do not assign it a hotkey, then it should show up back in the macro-editor “Obsidian Commands” field as an option to insert that file directly, without having to pick a template from the selector. So: trashcan the current step 2 of your macro, use the “Obsidian Commands” field to find the “Templater: Insert” command for your template, then click the “Add” button to the right of that field and you should have a new step 2! Does this work?
If I figure out why your much-more-logical-to-me original macro did not work, I’ll edit this post, but I wanted to put the workaround out there!
EDIT: As far as I can tell, the “Template” button/choice in QuickAdd is for creating new files that are pre-filled with a template, so it’s more of an alternative to the Capture, rather than something that goes with it. I’ve been wishing for weeks for better documentation for QuickAdd!
Dang, almost. If I use your approach, now it’s appending the frontmatter to the tail of the file. Reordering the Template and Capture pieces makes no difference. It’s as though everything maybe happens at once instead of in any order?
Oh, whoops! The cursor must get put at the beginning of the file instead of the end after the capture. Untested thought: if at the bottom of your capture format text area, on a new line after the ending ---, you put
<% tp.file.cursor(1) %>
does that do anything?
I will attempt to test some other things in parallel while you test that one!
No, that did not change anything other than now it appends that to the end of the file as well of course. I think that for any of this to work correctly, the Macro piece has to be executed fully and the file in place for the Template to do its magic. So adding more templater stuff to the macro makes no difference. The trouble is that the file is not “ready” when the Template is applied. So <% tp.frontmatter.context %> has no frontmatter to refer to. However, the <% tp %> code is removed from the file, so Templater is doing something, I’m confused. I think it’s all happening at the same time so we have races.
Yes you are exactly right about the timing! Thankfully the QuickAdd macro editor screen has the ability to add in waits via that little clock button below the list of steps. It adds a delay in ms. You’ll want to move it so that it is step 2, between the capture and the template insertion. Click the number of ms to edit: when I tried 500ms just now it was not enough, 2000ms (2s) was more than enough, I didn’t experiment more than that.
You do need to move your cursor to the end of the file for template insert; add the extra line at the bottom of your capture format from my previous post: <% tp.file.cursor(1) %> Then check your Templater settings that you have automatically jump to cursor enabled. If you don’t wish to have that enabled, you can add a step to the macro with the equivalent Templater command to jump to the cursor right after step 1 and before the pause.
In short, you were exactly right about the cause: timing and the file not being “in place” when calling the template, where (in practical terms) “in place” means getting the front matter into Obsidian’s cache. By adding a pause in the macro, we can solve it all in the same macro!
Getting even closer! Adding the time delay helped in that I am now seeing my frontmatter variables replaced, but I’m still getting the template inserted BEFORE the frontmatter instead of after. I do have the “jump to cursor” enabled, and I’m using tp.file.cursor(1). I want the cursor to be after the frontmatter. I looked at the docs for tp.file.cursor at tp.file - Templater and it is absolutely incomprehensible to the non-initiate. Perhaps you can explain what it means. LOL.
Odd that we’re getting different behavior between our vaults! I’ll close and re-open everything on my side to make sure that is not the issue. Oh, I also just noticed you have insider status - I do not, so my version of Obsidian might be different from yours. My extremely fuzzy understanding of the various forum and GitHub discussions on the API changes in the 0.15 versions of Obsidian suggest this might matter. Software!
A couple concrete questions, since I might not be able to get the same thing to happen over here: can you see a cursor anywhere in your new file during the 2 second wait? Can you manually click at the end of the file during the wait time, and if so does a cursor appear? Does the tp.file.cursor(1) disappear immediately (it should!) or stick around for the entire 2 seconds?
Watching carefully, I can see that after the first step completes, the cursor is blinking at the TOP of the file. Again, since I don’t know what tp.file.cursor() means I cannot understand what to make of that… and yes the tp.file.cursor(1) is visible (does NOT disappear) before Templater kicks in, which makes sense to me, since I think that command that only disappears during Templater parsing.
my version of Obsidian might be different from yours
We are on different versions, I’m still on whatever the maximum of 0.14 was. I don’t know if it matters, but since you are seeing a flashing cursor the difference I was worried about isn’t the issue!
For me, Templater’s processing kicks in twice, once automatically from the “Capture”, which removes the tp.file.cursor(1) nonsense and puts the cursor there, and then the second time after the two second wait when it’s explicitly invoked. I think I remember reading in the QuickAdd documentation about the automatic invoke during capture (though it cannot find the frontmatter then - I tested that earlier - due to the timing issue you identified). I’ll check at some point and edit this post.
Diversion - what does tp.file.cursor do?
I agree that the documentation for tp.file.cursor does not make much sense, but I have done a little experimenting and using it once it simply moves the cursor to the spot where the command was, just like you clicked right there. I use it in my daily notes template to put my cursor after the frontmatter and first heading; it saves me a click the first time I open the file.
The way I imagine people using the “order” argument is like those forms where you can jump to the next field by hitting the “Tab” key: if you put tp.cursor(1)tp.cursor(2) etc. on different lines of the file, you can jump to those lines sequentially by invoking the “Templater: Jump to next cursor location” command or hotkey. However, they disappear once used, so you can’t go back to the previous spot or anything flexible like that.
Back to solving your question:
More work-around for this macro, adding before your current step 2: a new step 2 with another delay (this one can be shorter, I think) and then a new step 3 another Obsidian Command “Templater: Jump to Next Cursor location” (or equivalently, “Templater: Replace templates in active file” since this is the only one there at the moment). That really should move the cursor and remove the tp.file.cursor(1) text!! If it doesn’t, I think we might need help from someone who understands the 0.15 changes. Then after this new stuff will be your 2sec wait (currently step 2, will be step 4) where you should be able to see the cursor correctly at the bottom of the file, and last the template insert (currently step 3, will be step 5). I really hope this works…
