Add denote link type

[jarofromel]

Hello,
I use denote (note-taking approach in emacs) which uses its own link type.
The notes (files) have file-naming scheme -> 20200927T000622--awk-learning-sources.org.
The link to this file is [[denote:20200927T000622][awk learning sources]], so it is like the file type link but only the first part (yyyymmddThhmmss) is used in the link.
Also the link can contain heading part -> [denote:20200927T000622::*heading] or [denote:20200927T000622::#CUSTOM-ID].

I understand that adding custom link types besides org ones is extra work. My arguments are that Denote with Org-roam are probably most popular note-taking packages (in Emacs ecosystem), and maybe that implementation would be similar to file link type (my guess).

Thank for potentially considering this issue. Also thanks for very useful app it helps a lot with using my notes in Android.

[amake]

Some issues I see:

• Orgro will not know how to resolve denote-directory. If it is a flat directory and the current document is inside denote-directory then it will just be ./, but any other cases are unclear.
• To compute the actual filename it looks like I would have to completely reimplement the sluggification logic
• Even with all of the above solved, there are numerous ways to customize the mapping between link and filename (signatures, denote-file-name-components-order, etc.). All of this would need to be reimplemented.

Supporting all of this would be outside of Orgro's remit. If there is a reasonable subset then I might consider it, if it would be of significant value to users.

[amake]

Denote's core link-resolving logic requires recursively iterating over all files in denote-directory looking for the one with the portion considered an ID.

  denote--directory-all-files-recursively()
  denote--directory-get-files()
  denote-directory-files()
  denote-get-path-by-id("20250103T082129")
  denote-link--ol-resolve-link-to-target("20250103T082129::#h:9B4FF9B7-4BA2-4B09-84F1-907A2AB35BD4")
  (org-link-open-as-file (denote-link--ol-resolve-link-to-target link) nil)
  denote-link-ol-follow("20250103T082129::#h:9B4FF9B7-4BA2-4B09-84F1-907A2AB35BD4")
  org-link-open((link (:standard-properties [116 nil 183 197 199 0 nil nil nil nil nil nil nil nil #<buffer 20250103T082153--another-test__done.org> nil nil (paragraph (:standard-properties [116 116 116 200 200 0 nil nil element t nil nil nil nil #<buffer 20250103T082153--another-test__done.org> nil nil (section ...)]))] :type "denote" :type-explicit-p t :path "20250103T082129::#h:9B4FF9B7-4BA2-4B09-84F1-907A2AB35BD4" :format bracket :raw-link "denote:20250103T082129::#h:9B4FF9B7-4BA2-4B09-84F1-907A2AB35BD4" :application nil :search-option nil)) nil)
  org-open-at-point(nil)
  funcall-interactively(org-open-at-point nil)
  command-execute(org-open-at-point)

This is quite cumbersome on iOS and Android.

[jarofromel]

Some issues I see:

• Orgro will not know how to resolve denote-directory. If it is a flat directory and the current document is inside denote-directory then it will just be ./, but any other cases are unclear.

• To compute the actual filename it looks like I would have to completely reimplement the sluggification logic

• Even with all of the above solved, there are numerous ways to customize the mapping between link and filename (signatures, denote-file-name-components-order, etc.). All of this would need to be reimplemented.

Supporting all of this would be outside of Orgro's remit. If there is a reasonable subset then I might consider it, if it would be of significant value to users.

Thanks for the answer. I understand that supporting full Denote functionality is out of the scope and limited functionality is in "maybe" state.

What I think the limited set is (based on protesilaos/denote#539):

• all Denote files are in the same folder
• only the default filename scheme is used DATE==SIGNATURE--TITLE__KEYWORDS.EXTENSION

Denote's core link-resolving logic requires recursively iterating over all files in denote-directory looking for the one with the portion considered an ID.

  denote--directory-all-files-recursively()
  denote--directory-get-files() ....................

This is quite cumbersome on iOS and Android.

That could be simplified to match only the DATE part at the beginning of the filename (supposing the default filename scheme). The DATE part is considered to be unique identifier, so the match should return only one file.

[amake]

I think you misunderstand. If the exact file name is not present in the link, then I have to iterate over the filesystem in order to look for the one with the right prefix (regardless of whether that's a date or otherwise). This iteration is what's cumbersome, due to how filesystem access works on mobile platforms.

[jarofromel]

I see. You are right I didn't know about the filesystem internals on mobile. Now I understand the need to implement the whole slugification logic which is quite a lot of work. Thanks a lot for your time and input.
Feel free to close or keep it opened.