About renaming files and maintaining note links about denote

[kaushalmodi]

Copying @jackbaty because from the commit messages, I believe that he might be heavily using the renaming feature.

[protesilaos]

I feel like it will break all the inter-linked notes

This is true with the existing backlinking facility. Though the proof-of-concept denote-link-backlinks uses only the identifier to conduct its search. So it should work properly.

Taking a step back, only the identifier should be constant. If we hardcode file paths, we will get into trouble.

I don't have a solution except a vague idea that when the files are renamed in dired, there should be a search/replace operation

Yes, I think the renaming facility will eventually be expanded to operate on file contents as well. It is why I created denote-retrieve.el, so that both denote-dired.el and denote-link.el can share the code.

[protesilaos]

To test what I just noted about the proof-of-concept backlinking.

I had a sample note that I created links to from four other notes. I then renamed it:

Rename 20220611T130907--my-new-test-for-backlinks__denote_testing.org to 20220611T130907--my-renamed-test-for-backlinks__denote_testing.org?

Visited the newly named file and M-x denote-link-backlinks: it worked!

[protesilaos]

What I just noticed about the renaming is that it should also update the buffer-name to avoid possible confusiton. But let's keep using it for a while to be sure.

[kaushalmodi]

This is true with the existing backlinking facility.

I was referring to just the inserting links. This issue would be there even if the backlinking isn't used.

I have pushed a quick test repo here: https://gitlab.com/kaushalmodi/denote-test

From that repo, the 20220612T102752--linking-to-other-notes__link_test.org note points to the other note 20220611T113742--denote__note_org.org. If 20220611T113742--denote__note_org.org is renamed, we would need to update the links to that file in the whole denote-directory.

:PROPERTIES:
:ID: 20220612T102752
:END:
#+title:    Linking to other notes
#+date:     [2022-06-12 Sun 10:27]
#+filetags: link  test

[[file:20220611T113742--denote__note_org.org][denote (20220611T113742)]]

[protesilaos]

Indeed, those are part of the problem with the current design. I think the solution is to use an identifier-based link. Anything else cannot be relied upon.

I have been thinking about how best to do this. What you shared before in issue 8 with org-id is one option. Maybe there is scope for another that does not depend on anything Org-specific.

While still fuzzy in my mind, the file-name-completion is already something that is used in denote-link.el, so there is at least one way to expand a file name given a known variable.

[protesilaos]

To explain what I am saying about ID-only links (however we go about implementing them).

I created two new .txt notes. The one has only the front matter. The other is this:

title:      Just to demo the identifier as a link in itself
date:       2022-06-12
tags:       denote  testing
identifier: 20220612T180602
---------------------------

Place point over the following identifier and type C-x C-f (find-file)
followed by M-n:

20220612T180621

If the identifier matches a file  in the current directory,, it will be
expanded.

[kaushalmodi]

@jerm-the-wyrm From your comment in #8 (comment):

I was thinking that instead of having the link be like [[denote:20220606T164519]] we could instead have it show up as [[denote:20220612T144708--test-note__testing.org:20220612T144708][Test Note]] allowing the identifier after the filename to be used in a similar manner to =org-id= which will help with #13

I didn't understand how that suggestion will solve this issue with renaming. Your suggestion instead hard-codes the file names in links which are prone to being renamed.

@protesilaos About denote: links, are we re-inventing what org-id already does? I understand that org-id will work only with Org files. But I think that if denote implements a denote: type link, that will be a faction in the id: links that many users are already familiar with. Instead, can denote extend the id: links to work with Markdown and plain text as well? I see from the introduction text that denote does not want to rely on other libraries. So I don't know what's the right way forward for this.

[protesilaos]

@protesilaos About denote: links, are we re-inventing what org-id
already does? I understand that org-id will work only with Org
files. But I think that if denote implements a denote: type link, that
will be a faction in the id: links that many users are already
familiar with. Instead, can denote extend the id: links to work with
Markdown and plain text as well? I see from the introduction text that
denote does not want to rely on other libraries. So I don't know
what's the right way forward for this.

In that case we do not want to re-invent it: we will use org-id. And
yes, finding a smart way to extend it to other file types is the way
forward. I just put the suggestion out there to discuss its merits.

I didn't understand how that suggestion will solve this issue with
renaming. Your suggestion instead hard-codes the file names in links
which are prone to being renamed.

I also think that will complicate things. In general, we should assume
that anything other than the identifier is an unknown and subject to
change. It is important to have robust links, as this will determine
the overall usability of the package once the user starts accumulating
hundreds of notes.

[protesilaos]

I am closing this to consolidate the discussion here: #8 (comment)