Question about workflow, org-id-get-create, and org-store-link.

EDIT: This has been solved in the comments. It seems to me that uuid is "the way to go" for creating IDs for linking since they are guaranteed unique, and will survive movement of a heading to another tree or file. Right? So I'm just starting to get into the whole linking-thingy in org mode, and it seems like I'll need to call org-id-get-create just about every time before org-store-link. Rather than make both calls each time, would it make sense to create a new function, my-org-id-get-create-and-store-link, so it simply calls both functions? Could someone help me with a function that will do both id creating and link storing? I do have the following set: (setq org-id-link-to-org-use-id t) Such a function must have been done before a thousand times, right? Or am I missing something in terms of id creation and workflow?

Check out the variable `org-id-link-to-org-use-id`. You probably want to set it to `t`

Check out the description of my question. ;)

(setq org-id-link-to-org-use-id 'create-if-interactive) or (setq org-id-link-to-org-use-id 'create-if-interactive-and-no-custom-id)

[removed]

Wow. I don’t know how I missed that! Sorry about that 🤦‍♂️ At any rate I think the behavior you expect is the one I see when I set that variable to `t`. I’ll double check tomorrow when I get back to my computer.

Ok now I get to do the same. 🤦‍♂️ Yes, the behavior is exactly what I want it to be, I don't need to write another function for it. Given that I set that variable properly, `M-x org-id-store-link` does, in fact, create a UUID if/when needed. 🤦‍♂️

Yeah I'm sure I'll want to revisit that at some time, thanks.

You might want to read [this](https://karl-voit.at/2019/11/16/UOMF-Linking-Headings/) and [that](https://karl-voit.at/2020/07/22/org-super-links/) article of mine where I explain how I'm generating human-readable IDs when I create a link. *Ceterum autem censeo* [*don't contribute anything relevant in web forums like Reddit only*](https://karl-voit.at/2020/10/23/avoid-web-forums)

Thank you! I'll probably switch over to that at some point. I have a certain structure to my emacs learning path. Most of my learning is based on ad-hoc "emacs problem solving as I go". (I need to (or want to) do something RIGHT NOW, so how do I do that?) That type of learning tends to be my highest motivation. But after that, I'm also structuring my "learning path": * PROJ Emacs Learning Path ** TODO [#A] Current Emacs Learning Subject: Capture/Template ** Ordered List for Next Learning Subject... ** Potential Options and Meta Options to add to the Ordered List... As you can see, my next step is to learn about Capture Templates! So I'm still VERY early in my learning path. But I've added https://karl-voit.at/2019/09/25/using-orgmode to the "Potential Options" section. The "problem" with your articles is that they tend to be a rabbit hole, haha. > Ceterum autem censeo I already read that article! It has certainly made an impact in my thinking about my future direction in data collection and blogging. And I also just now looked up what that latin phrase means. Hammer the message away, haha.

You live and you learn I guess 😂

In my case I am doing something similar to /u/publicvoit (as I am a fan of his work anyway, generally speaking). However in my case I settled on what I call [ostrta-id-4](https://git.sr.ht/~trs-80/ostrta-spec/tree/HEAD/Specifications.md#ostrta-id-n) format, in other words an ISO-like date to 4 digit precision in the time part (in other words, minute precision), for example: YYYY-MM-DD-HHMM As long as I do not generate a new one more than once per minute[0], it will be a unique ID. These also have the advantage of having at least some semantic meaning (personally, I detest UUIDs as being not only unnecessarily long IMO, but quite ugly). In fact I read (and was convinced by) similar points in some article from one of Zettlekasten guys about these sort of date based IDs. Anyway I do not always generate ID's upon creation of every headline, only upon creation of (Org Mode) links. I do however, fairly religously create a CREATED timestamp (LOGBOOK) entry whenever creating a new headline. The function `ostrta-org-id-create` looks for this CREATED (or earliest) LOGBOOK entry, and uses its timestamp when present, in order to give the headline an ID of when it was actually created (falling back to current timestamp when not present). Finally, I wrote the function below to insure there was an ID, and added that as advice before `org-store-link`. Unfortunately the `ostrta-id` stuff is (as yet) unreleased (I need to clean it up and publish). But maybe this post gives people some things to consider anyway, in the meantime. [0] I have some other functions which check for this, too. (defun my-org-insure-ostrta-id (_arg &optional _interactive) "When no ID present, create one with `ostrta-org-id-create'. When an ID exists, check it with `ostrta-id-p', and exit with error if it's not a valid ostrta-id. Intended as advice before `org-store-link'. Which is why there are 2 unused args, solely to match that function." (when (string= major-mode "org-mode") (let ((old-id (org-id-get))) (if (null old-id) (ostrta-org-id-create) (unless (ostrta-id-p old-id) (user-error "ID is not a valid ostrta-id")))))) (advice-add 'org-store-link :before #'my-org-insure-ostrta-id)

Thanks! I really like the idea of CREATED timestamps, since that helps document one's timeline. Also like reverting to <CREATED> if/when creating an ID, as that's more meaningful. Furthermore, I can see how delaying the time between creating a headline and creating its ID might give a headline some "ripening" time, in which the headline name, tags, etc. could be more settled. I see your full ID can be much more than just a timestamp: timestamp-id [_description...] [--[tag...]-another_tag...] [.ext] With your slightly more concrete example: YYYY-MM-DD-HHMM_description_text_here--tag1-tag2-tag3_with_spaces.jpg I'll probably check back with your ID spec (and filing system spec) when I get to that point. What do you call these classes of ID? They aren't uuid's since, technically speaking, they are not guaranteed unique. I might call them pgid's, "Pretty Good IDs". That might be a little strong comparing with PGP. Perhaps fgids, "Fairly Good IDs", haha. Thanks again! trs 80 was my first computer :)

> I really like the idea of CREATED timestamps, since that helps document one's timeline. Thanks! Of course, I agree! :) In fact, I made a function to add a CREATED (or UPDATED) logbook entry, and then change the TODO state back to whatever it was before, in order to be able to make these entries without actually affecting the real TODO state. But this way they still appear in the LOGBOOK drawer, with a timestamp (and a comment if I want). It's all very quick and easy that way. If anyone is interested, I can post it. > I can see how delaying the time between creating a headline and creating its ID might give a headline some "ripening" time, in which the headline name, tags, etc. could be more settled. In my system, the ID is what remains fixed. You could completely change the headline, move the subtree to another file, etc. and it wouldn't matter. Which is sort of the whole point of doing it this way. Mainly, for exactly the reason you state. The main reason for waiting, is not to proliferate IDs unnecessarily. So the CREATED timestamp way is a good compromise, as it preserves the original creation date, which then can be used later (if/when needed) upon ID creation. > I see your full ID can be much more than just a timestamp To be clear, the tags and stuff are only part of the filename spec, and not the ID spec. Although I use the ID spec for the first part of the filename spec, as well as Org Mode IDs. But only in filenames do I add other stuff like description and tags. Because in Org Mode headlines, there are other places to put that metadata (PROPERTIES, the headline itself, etc.). Although I have thought it would be really nice to be able to mouse over an Org link (with this style of ID, which otherwise has no context) and get the current headline in the mouse tooltip. In fact I hope to get around to implementing that "SOMEDAY/MAYBE". ;) Incidentally, I guess that is biggest place where my implementation differs from what /u/karlvoit links to elsewhere in this thread, as he is at least including some text in the ID itself. I just wanted to be able to completely and arbitrarily change the headline at any time, and so I stick with a strictly date based ID. So from my point of view, implementing the headline tooltip on mouseover is a better way to go about that. > What do you call these classes of ID? I don't have a name for them, other than, I dunno, 'ISO-like date based Org Mode IDs' or something. You are correct, they are not technically UUIDs, although for me they certainly function that way. A true UUID, IMO, is actually overkill, as that would only be needed if all of us were collectively editing some huge common set of global notes. However, within the scope of an individual's notes, I think a timestamp based ID, down to resolution of second (or even minute) is perfectly acceptable, and essentially guaranteed to be unique. In file names (photos for example) I use ostrta-id-6 which gives me resolution to the second. But in Org Mode headlines, I find that minute resolution is (usually) enough. You could always simply use ostrta-id-6 though if you were more in the habit of rapid-fire creating headlines though.

> The "problem" with your articles is that they tend to be a rabbit hole, haha I know what you mean, but I can highly recommend studying Karl's stuff! :) Not only have I learned a lot from it, but in fact it forms the basis/inspiration for some of my own work (e.g., [ostrta-spec](https://sr.ht/~trs-80/ostrta-spec/), and the (as-yet-unpublished) Elisp implementation of same. In fairness, it takes years though. I think I read that stuff many years ago. A few years ago, I started implementing it. Published the spec a little over a year ago now. And still have not published the Elisp implementation (even though I use it every day personally). I guess my point is, Emacs / Org Mode are a marathon[0], not a sprint. You are already doing well by taking down notes of things you are interested in. I do the same. Lots of "SOMEDAY/MAYBE" in my files (which appears as an inactive state, so as not to clutter the agenda). Cheers! [0] In fact I suppose each could be considered a marathon in their own right, lol!

I almost forgot, in newer versions of Org Mode, you should be able to specify a string (suitable as an argument to `format-time-string`) as a new way of creating your own custom timestamp based IDs. This would obviate the need of specialized functions discussed elsewhere in this thread. That was something I had brought up on the mailing list some time ago, and it ended up being implemented! My 15 minutes of fame! :) As I had realized, Org Mode will accept just about anything as an ID.

> It's all very quick and easy that way. If anyone is interested, I can post it. Please do! And thanks again, this is all very educational.

FYI: While my blog articles may feature an older version of `my-id-get-or-generate`, the version [in my configuration](https://github.com/novoid/dot-emacs/blob/master/config.org) does re-use the `CREATED` timestamp for the ID as well.

Between the first idea and the actual start of the implementation of [lazyblorg](https://github.com/novoid/lazyblorg) there was a time span of several years. ;-) [filetags](https://github.com/novoid/filetags) and its companion tools is a direct result of [my PhD projects](https://karl-voit.at/tagstore/en/papers.shtml) with [tagstore](https://karl-voit.at/tagstore/). For the basic concept of filetags, I worked with file tagging methods for at least six years. I don't say that there needs to be a long concept phase. It just happened to be it that way for those examples. So I guess it's not that unusual to run marathons if you are focusing on the long run. Oh, what a play of words. Oh, and something else came to my mind: the idea for my PIM book is probably more than ten years old and I still didn't start the hot phase yet. I don't think that the book will hit the market within the next five years. But I've converted my PIM lecture structure to meet the draft structure of my book. This way, I'm using my students as guinea pigs to polish the structure and maybe bits of the content as well. I'm far from happy with its current status but my goal is to publish a book that's valid for at least a couple of decades and not just months or years.

>Ceterum autem censeo A bit of a spoiler alarm: at [GLT](https://linuxtage.at/) 22, there will be [a 45min talk on that topic](https://pretalx.linuxtage.at/glt22/schedule/#). People might attend the talk in person. After the event, there will be an online video. Follow my public/media appearances of any kind on [my blog page](https://karl-voit.at/clippings/). I do recommend [following my feeds](https://karl-voit.at/how-to-use-public-voit/).

(defun my-org-todo-then-return-state () "Call regular `org-todo' to change state and enter notes, but return to previous state immediately after. This is intended for states like 'CREATED' and 'CHANGED' where you only want to make a (timestamped) note in the logbook, but change back to the previous state afterward." (interactive) (let* ((todoval (cdr (assoc "TODO" (org-entry-properties (point) 'special)))) (oldval (if (null todoval) "" todoval))) (org-todo) (org-todo oldval))) I forget now what default keybindings are for changing TODO state, but I have this set to =C-c t= and `org-todo` bound to =C-c C-t= (to actually change state).