Replies: 2 comments 4 replies
-
|
Thanks for the kind words. To provide some background: I personally don't use Org Roam or logseq. I am somewhat familiar with how Org Roam works mostly through research relating to #17. I don't know anything about logseq. Note that Orgro does support ID links in 1.19.0 (currently out for iOS; Google Play and F-Droid are in processing), but only when they point to sections within the currently open file. You're right that currently Orgro isn't capable of being a comfortable Org Roam browser due to the inability to resolve ID links across files. There are several approaches I can think of to improve the situation, but I haven't had time to look into which, if any, might be most fruitful:
Note that all of the above supposes that Orgro actually has persistent permission to access to the directory tree in which all of these files are stored. As you can see in the FAQ that's actually a fairly tall order—almost no third-party apps support this at all, so in practice you're mostly limited to local storage. To answer your specific questions:
ID links are partially supported in 1.19.0. The further support you desire may be possible per above.
Sure, that would be nice. The major difficulty this adds on top of ID linking is providing a reasonable UI. So I would say it's at least twice the work of ID linking.
It depends a bit what you mean by that exactly. Orgro can open multiple files just fine right now: if you open a file, give Orgro directory access, and open a relative file link then it will open the second file on top of the first one. You can give Orgro access to as many directory trees as you want (it will always prompt you if it detects that the current file has relative links but the app doesn't yet have access to a directory that includes the current file). But that's probably not what you mean, so perhaps you could clarify. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the well put answer. I'll start by clarifying what you wondered.
What I asked for was actually pretty much answered by the rest of what you wrote. That relates to the FAQ you linked to. And that folder access seems to be pretty limited in other 3:rd party apps. Working Copy on iOS seems to allow it though! And I'd wager that the correct path forward, if taken, is to rely on that permission to be handed out. Some comments on the rest of what you wrote below:
Aha, didn't know! Probably because the links I have almost never goes between items in the same files.
A fair assessment. Anything half-baked or relying on the Emacs or Org roam caches probably isn't worth it in my humble opinion. Option 2 would require a manual visit of potentially thousands of files before links would work. That doesn't scale well. Option 3 would put dependencies to software on other systems. Probably also a clunky solution, even if the sqlite cache probably would fulfill the information-requirements if it was available. Which basically only leaves option 1. Which would be awesome if possible! I mean, really awesome! But maybe quite a lot of work then, as you elude to. |
Beta Was this translation helpful? Give feedback.
-
The trick with apps like this or GitJournal is that they own the files because they create them on the device by performing Orgro doesn't own any of the files it opens, and even if you provide directory access permissions it can't assume that files don't link to outside of the allowed directory tree. This makes things very complicated in the general case. As for indexing strategies, I agree that clearly (1) is the best. I was worried that would be horrifically heavyweight, and it would be if I indexed files with the same general-use parsing I use when opening files. But I realized that I can get away with something much more lightweight: stream file content linewise and just extract the IDs e.g. with I can't say when I'll be able to actually work on this, but at the very least I think there is a reasonable path forward. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure if this is true for Working Copy. I tried using beorg together with Working Copy and it worked just fine. Promising with the finding about ID's. What you describe is basically what the Emacs Org ID code does as well, when collecting all the ID's together into the internal cache. Also, don't feel any pressure from me! I'm just checking in, and highlighting an area that would be very nice from my point of view. Definitely not expecting anything. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the tip about Working Copy. It looks like that's one of the very few third-party apps that actually does support directory permissions. I'll add it to the FAQ.
No worries. I'm thinking this might be the next big thing I work on for Orgro so I'm just trying to gather as much information as possible. |
Beta Was this translation helpful? Give feedback.
-
|
Another thing I should mention is
It would be super helpful if I could find an existing Org Roam database that I could use for testing and to better understand the scale of what is required. If anyone happens to know of someone who publishes their database please let me know. Edit: Here's one: https://github.com/jethrokuan/braindump/tree/master/org |
Beta Was this translation helpful? Give feedback.
-
Hi,
First I want to say thanks for this very neat Org mode file viewer, it really is great at presenting the content of an Org mode file!
I have a question on compatability with a workflow that is becoming more and more popular (to my understanding), that builds on the Zettelkasten approach of many small notes. I'm thinking in particular of the Org Roam movement. But also of logseq.
With Org roam, links between concepts are created using ID links (in the active v2 branch). To follow them the software would need to have the knowledge of available IDs. Something which requires parsing of not only one file but a collection of files. A folder of files :-)
Another thing when working in this Zettelkasten way is that one often find oneself searching across the whole collection of files. Something which also requires the knowledge of the whole collection.
I realize all of the things above require something outside of what orgro provides today. But I'm with this post simply wondering what you, as the excellent developer of this software and with the knowledge you have, think about the topics mentioned above?
In short:
Cheers!
Beta Was this translation helpful? Give feedback.
All reactions