I would like the properties drawer generated by org-id-store-link to be lowercase, so :properties: rather than :PROPERTIES: etc.
I looked at the documentation for org-id-store-link, but I cannot find a way to do this. I searched for relevant variables too, but did not find any.
I think this means I have to modify the function itself, but how would I actually do this? Unless I’ve missed a relevant variable.
I believe it’s done by function org-insert-property-drawer. The uppercase “PROPERTIES” and “END” are hardcoded. The docstring says “Do nothing if the drawer already exists.” so you have three options.
:after (probably after org-id-store-link to narrow the scope of adviceorg-insert-property-drawer to add property before… (the scope may be too big…)I’d lean to Option #2 above, but #1 is easy to implement – and accept the fact you’d need to look after the monitor the code every time you upgrade Org.
EDIT and P.S. I don’t publish Org-roam notes directly, so I cannot respond to the other query of yours about export.
Thank you, I’d lean towards option 2 as well.
Where would I change this? I assume in my use-package org’s :config, and I’d use cl-defmethod with :around. I did the same thing for overriding node titles.
What do you mean by “scope of advice”?
Yes, it’s a good place.
No, not cl-defmethod. I’d use add-advice and :after combinator. Refer to (info "(elisp)Advising Functions") – you should be able to evaluate this expression to get to the Info page. org-id-store-link is a function so I don’t think cl-defmethod will work (let me know if I am mistaken).
Edit: it should be advice-add (function) not add-advice.
OK, I’ll look at that page.
Advising a function should be done with a caution because it influences any part of Emacs that use the same original function. The more localized the original function, the less chance you inadvertently introduce an unintended problem — a bug by your custom code. This is what I was trying to point to by “scope of advice”. org-id-store-link is likely to be more localized than org-insert-property-drawer, thus safer to advise — I could be wrong but this is what I was going for.
I get it now. I agree, the scope of org-id-store-link seems smaller.
But I do want to have lowercase properties drawer everywhere, so it does seem to make sense to modify the one with broadest scope of advice.
I am not sure if using lowercase for :PROPERTIES: and :END: is a good idea – it seems that Org assumes they are uppercase by the looks of the function. It may just work fine, but some internal search / regexp code may be case-sensitive and potentially behave unexpectedly.
An alternative idea may be hiding or prettifying these syntactic elements. As an example, see this post of mine and the thread around it.
This is just a suggestion. Lowercasing might just work fine. But if your intent is purely for aesthetics, then the suggestion above might save some troubles long term.
Edit. In the post I linked, I said “Use lower case for properties meta data” – I no longer do it and I have simplified my setup. Today I use org-modern to simplify the UI and my setup for Org mode.
I use lowercase for file-level properties drawer and have never run into issues, it could work differently for headers but so far no issues with that either.
Yes it’s for aesthetics.
That post of yours is helpful anyway, I wanted to know how to hide all those elements anyway.