-
-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Canonical (probably?) way to set file ID in Org #8
Comments
[I might have gone overboard with this much chatter on the GitHub Issues in a single day. I will stop now.] |
Yes, this is a good use-case and I was exploring it myself. But...
Have you tried it? I ran a test this morning and did it again. Instead Maybe I am doing something wrong.
Haha, no worries! As you will notice from the times of the commits I |
Yes. May be you need to update the After you create the 2 Org files I saw in that example. eval that lisp form and then try to
I am enjoying following the activity in this project! And you are welcome! |
Here's the entire recipe to make the Org ID linking work in a single Org file:
|
Okay, I can reproduce it now. The downside is that we will be depending Maybe we can provide this an an option? It will need more work though. Also, we need to be careful not to re-invent org-roam: it already is Since we are considering deeper intergration with Org, what are your
|
That's true. It would be good to not have custom links for this because the
The linking using The upside of this ID format is that if user wants to use
That was my fear as well as I was suggesting this .. I am being careful so that the features of denote don't converge with that of Org Roam. |
This "hidden option" lets the user do something like this (I prepend > to escape the #): > (setq denote-org-front-matter > ":PROPERTIES: > :ID: %4$s > :END: > #+title: %1$s > #+date: %2$s > #+filetags: %3$s > #+identifier: %4$s > \n") Ultimately though, it gives us more flexibility if we ever want to support extra features. One such feature is the ability to create links using the org-id.el library. See issue 8 over at the GitHub mirror, with feedback from Kaushal Modi: <#8>.
If the identifier is internally set to the ID property for the default file type (Org), will that need updating just the regexp for identifer search? If so, can we make it a default so that the ID goes where Org users would typically expect it? This is of course given that it doesn't overly complicate your plan for creating links and updating backlinks. |
Fixes issue 10 over at the Github mirror: <protesilaos#10>. This regexp update now also matches the ID property. Refer issue 8 at the Github mirror: <protesilaos#8>.
This is the same as what we discussed in #10, right?
I think we should do the right thing based on what the user expects. Note though that the linking/backlinking facility still needs work. Damien Cassou raised some good points on the mailing about not automatically inserting backlinks, but using a dynamically generated list instead: https://lists.sr.ht/~protesilaos/denote/%3C87edzvd5oz.fsf%40cassou.me%3E#%3C87edzvd5oz.fsf@cassou.me%3E. In the meantime, I wrote a proof-of-concept |
The principle I want to abide by is to have a solid but mostly generic linking facility which can work with all file formats. We can then add extensions to this core, depending on the case. I am open to ideas though and am willing to make breaking changes (as we did when we revised the file-naming scheme). |
Yes, denote-link and backlink insertion worked after the regexp update yesterday, without needing to add I can test this out a bit more thoroughly tomorrow and update the status here.
Yes, I also don't like the concept of modifying the user-controlled file. I'll try out your proof of concept tomorrow.
I believe that linking across multiple file formats already works (based on the code that I have read so far). I'll confirm this as the part of my more thorough testing tomorrow. |
Thank you!
Good! I think we will reach consensus here. As Damien argued on the The proof-of-concept feels like a step in the right direction. We are, We can even document CLI methods of getting the same results with
The linking itself works. Otherwise we need to tweak the formats. I am |
I was thinking that instead of having the link be like Doing this could open up the possibility of allowing identifiers to be placed at other points in the note perhaps under headings allowing for deeper notes while still maintaining the ability to link to individual ideas, these links could take the form of |
Hi @jerm-the-wyrm!
Just for me to be sure I understand your suggestion: we should visually |
Yes, that's exactly what i was going for! Edit: I'm @jerm-the-wyrm but using my old account that I forgot my login to and can't reset my password, but I'm still logged in on my phone |
It's very common to tweak/refactor sub-headings in posts. Having |
You make a great point about renaming headings, so perhaps it is better to just use the file name plus the identifier like this
Perhaps though the better solution is to create a function that runs when you invoke |
Hello again folks! An update on how things stand. I have created a custom Org hyperlink It also is like (info "(org) Search Options") And it works like The These behave in Org buffers just like ordinary I do not know of a method to define custom links for Markdown and there
With the current
I think what we will need in the future is a function to expand If we do that, we need another command to re-read and try to update any |
I'm being a devil's advocate here ..
|
That's a good thing. We need to assess this properly.
For the end-user, there should be no difference between (require 'org-id)
(setq org-id-extra-files (directory-files-recursively default-directory "\.org$")) This means that we make For context, I use Org for a lot of things on Emacs We then have to consider
Indeed. My expectation/hope is that we can cover those use-cases as |
Yes,
Correct. It needs to be required.
I am not very familiar with that flow. We will need to figure that out.
If you decide to support
Thank you. |
That would be undesirable, for sure. Looking at org-id.el, there is a lot of code not specific to what we
In principle, I am fine with this. I just have no idea how to proceed. By the way, do you know if (info "(org) Search Options") Or online: https://orgmode.org/manual/Search-Options.html. |
Hello again! Just to let you know that today I will start working on an implementation with |
@protesilaos Thank you for considering the use of |
@protesilaos Recently I fell in love with denote and decided to make a migration from org-roam to note. But the work is really cumbersome(I have thousands of notes), and it would be very convenient if denote can support org-id. I really like denote's reuse of existing ecosystems, which is concise and user-friendly. It's very customizable and extensible. Thank you Protesilaos, you got me a great present. |
Thanks @nowislewis! I am still working on this. It has taken me longer than expected but the plan has not changed. |
For a discussion, read issue 8 on the GitHub mirror: <#8>.
Just pushed support for The gist is this: (defcustom denote-use-org-id nil
"When non-nil use the ID property and link type in Org files.
To use the ID property, a PROPERTIES drawer is added to the top
of newly created notes. Furthermore, newly created links will
use the standard 'id:' hyperlink type instead of the custom
'denote:' type.
In practical terms, the ID ensures maximum compatibility with the
Org ecosystem.
When the value is nil, Denote uses a generic front matter for new
notes and links rely on the custom 'denote:' type (which should
behave the same as the standard 'file:' type).
Other files types beside Org always use the 'denote:' links and
keep their generic front matter."
:type 'boolean
:group 'denote) What do you think? Furthermore, do you think we can give this a thorough round of testing or should I release version |
Sorry forgot to link to the branch: https://github.com/protesilaos/denote/tree/org-id |
One problem I see with the I would prefer not to add such a drawer to plain text and Markdown: it should remain Org-specific. |
I test it, it works fine and even works on my origin org-roam files, the only thing I need to change is to add #+date and then denote will discover the note. And I will use denote-dired-rename to rename all files. |
I have to say, all of it works surprisingly well, the org-id support reduces me a lot of org-roam work that needs to be relinked |
I found a thing which is a bit repetitive, if I want to modify the tag of a file, I can't modify it directly in the file with #+filetag, but need to go to the dired and execute denote-dired-rename-file, and then select the title and modify tags in order, even though I don't want to change the tile and just want to add one more tags. I think it would be much more convenient to modify the file name or tags directly based on the file content (title, date, tag, etc.), or even a func which will refresh all file names under the path according to the content (title, date, tag, etc.). But now it's quite good that this kind of thing doesn't happen very often |
Can Org format use the property drawer format and rest others use the Looking at the commit, I noticed that a new Org format, with the ID property drawer is supported. Do we need that additional option? I'll try this out today. Thanks! |
For 0.1.0, may be allow a week's testing time? |
For a discussion, read issue 8 on the GitHub mirror: <protesilaos#8>.
Thanks @nowislewis for the feedback! I see that @kaushalmodi has a PR open, so we move to the technicalities. I am happy with the progress!
I already asked on emacs-devel if Denote can be added to GNU ELPA. Assuming the patch is applied right now, it will take another day or a bit more before the package is available. No pressure though. I will follow-up with version 0.2.0 shortly afterwards. But we might even manage to fit everything into 0.1.0, so let's see. |
All the changes are now in When we are in an Org file and link to, say, Markdown the link is always Please test it. I will now review the documentation for links and update the sample configuration. |
I should add here that if we use What do you think? |
👍 |
I have seen this in the Property Syntax section of the Org manual:
Org Roam is probably the only primary Org-related application that uses this feature tremendously, to set the Org Roam "note"s ID.
(PS: I don't use Org Roam myself, but I have seen quite a few examples.)
So an Org Roam file might look like:
I believe that Org Roam sets ID this way because the Org built-in library
org-id
supports this. If you requireorg-id
and eval(org-id-get)
in the above file, it will return "1e8ccec9-735d-41d0-b0cf-143d9c3e965d".So I couldn't help but draw a parallel between the
#+identifier
property created by denote (whendenote-file-type
is nil or Org) and the:ID:
property used by Org Roam.Here's an example file created by denote:
#+title
: ✔️ Canonical style of setting a file's title#+date
: ✔️ Canonical style of setting a file's date#+filetags
: ✔️ Canonical style of setting a file's tags#+identifier
: ❌ Canonical style of setting a file's unique IDBut the good thing is that the
#+identifier
value is indeed a unique ID. So that value doesn't need to be changed; it only needs to be presented in a different format.Suggested Org format
Now if you eval
(org-id-get)
in this file, it will return "20220610T134422"!Another benefit: Enables linking of files using Org ID
Example file 1
Example file 2
If your org ID extra files cache is updated (by evaluating
(setq org-id-extra-files (directory-files-recursively default-directory "\.org$"))
), and if you put the cursor on thatid:
link in idtest2 file and hitC-c C-o
, it will jump to the idtest1 file.The text was updated successfully, but these errors were encountered: