Make capturing more flexible by adding parameters to org-node-capture-target - #141
Make capturing more flexible by adding parameters to org-node-capture-target#141bgro wants to merge 1 commit into
Conversation
…apture-target. Signed-off-by: Bernd Grobauer <bernd.grobauer@krakel.de>
|
Thank you, I’ll look at this soon! |
|
I have been going a bit further on this, but don't want to add more changes before I know whether the direction is palatable to you. Please let me know whether I should update the PR with the following:
|
|
These are good ideas. (I'd also like to look at changing I agree about letting it be a function too. I am not sure yet if the design with an optional plist suits my tastes. But it occurs to me you could put any property-value pair in the capture template's main plist, like this: (setq org-capture-templates
'(("p" "Capture plain text into ID node" plain #'org-node-capture-target nil
:path "~/foo/bar")))Then inside As for Here's your code with some changes to make use of |
This is a proposal to make capturing using
org-capturea bit more flexible such that some use-cases thatorg-roam-captureallows can also be handled without extendingorg-capture.One such use-case is the ability to provide a directory in which a new file is to be generated per template. Currently,
org-nodeworks around this by allowing the user to configure whether she should be asked for the folder when a new file is created ... but it would be nicer if one could set specific folders for specific templates.This pull-request adds the possibility to provide a plist with parameters to
org-node-capture-templateforinfluencing the path for a new file. For usage in a capture template, In the result has to be wrapped in a nullary lambda function in the capture template:
(the change is backward compatible, i.e.,
(function org-node-capture-target)still works.)The following parameters exist:
:path: Provide the path of the directory in which the new file will be created:ask_pathAlways ask for the path, even iforg-node-file-directory-askis configured otherwisePossibly, a few more use-cases could be tackled with this approach.