Open degiz opened 2 years ago
I got same issue on Linux(NixOS appimage)
Confirmed online with v0.5.2.
The linked document is not included in the page graph, and the link it provides to the browser to follow is id://<uuid>
.
Any updates on this?
I just downloaded logseq to use with org-roam as an android client (or if in the mood for a gui application) this weekend and it looks like this is still an issue and links inserted from roam cannot be followed.
If you set :org-mode/insert-file-link? t
in config.edn
then you'll get links created in logseq that org-roam can follow, but not links that org-roam sees as backlinks.
I suppose for now using both org-roam v2 that uses uuids rather than file links and logseq together isn't an option.
Or maybe all of my issues are just due to #2286?
Related:
It seems the current resolution is WONTFIX
:
We don't plan to change this in the near future because it'll need a lot of changes in the current code. We'll revisit this later. Closing this now as all feature requests are managed in https://discuss.logseq.com/ now. This will be tracked on our roadmap. https://trello.com/c/zdRWuPZI/614-feat-allow-links-to-ids-that-are-not-uuid (link dead now)
@codygman My reading is that the WONTFIX applies only to using non-UUID IDs, and that UUID links are supposed to work.
I've made a kinda ad hoc converter (a one-way change from org-roam v2 to Logseq) if others are interested! https://github.com/TheLostLambda/org2seq
If you are actually interested in using it, feel free to get in touch and I can adapt the program to fit your needs / be a bit more general purpose!
Definitely doesn't work for block links though ;-;
It definitely seems like it should work. If I create a new node in org-roam v2 called foo, then link to a node called baz, then in logseq I cannot navigate from foo to the baz link. But, if I open baz, it shows foo as a linked reference:
Not really very familiar with clojure, but guessing one of the conditionals here fails, it falls through to the else, and generates an external link instead? (Can see it as a normal anchor tag and href using the inspector)
Basically for some reason, it seems to fail to identify org mode file, or the id:// protocol, and so it doesn't attempt to look up the associated block by UUID. Instead, it treats the link as an external link and creates an anchor tag as <a href="id://some-uuid-here">
The problem lies elsewhere. org-roam v2 puts the file id into properties at the top, and logseq reads the id as not the file id, but properties id
Changing the above line to
(= (string/lower-case (:protocol (second url))) "id")
allowed me to follow org roam v2 links in logseq desktop app. The graph still doesn't represent the org roam v2 links though. Still investigating why that might be. Seems like the datalog entries that represent these org roam v2 links aren't correct from what I've ascertained thus far. But I'm a complete clojure (and datalog) noob so take that with a grain of salt.
Hi guys. Thanks for the reporting. This will be fixed in the next release.
@llcc
After checking out your branch, the inability to follow org roam v2 links is indeed fixed. The branch doesn't seem to resolve the links not showing up in the graph, though. I dug through it a bit and managed to fix the graph links not showing up: https://github.com/logseq/logseq/compare/master...cartwmic:fix/org-roam-v2-link-regression
My solution seems a bit hacky though. It seems like the issue with the links not showing up has to do with there not being a :block/name
attribute for org roam v2 page/block references. So I grabbed the name for those references from the :block/properties
attribute instead and updated the node name mapping for the graph accordingly. I haven't been able to figure out the best place to fix the org roam block ref entities not having a :block/name
attribute (if that is a more desireable fix then what I have above).
Hi @cartwmic, Thanks a lot for the information. Will look into the latter later and fix it ASAP.
Did the concern raised by @cartwmic got fixed? If not, then please don't close this. @llcc
@khrm Thanks for the comment! The issue was closed automatically, I'll re-open it.
What's currently missing to move this forward? I'm willing dive into the code to adjsut this, as I finally have need to combine loqseq and org-roam due to my Emacs configuration not being portable to Windows and Mobile Phone.
What's currently missing to move this forward? I'm willing dive into the code to adjsut this, as I finally have need to combine loqseq and org-roam due to my Emacs configuration not being portable to Windows and Mobile Phone.
Hi, sorry for the delay. We were working on other things. It would be great if you can submit a PR.
Small follow-up:
Result:
Todo:
I can verify that navigating to pages created from org-roam and links created by org-roam based on UUIDs does work. A few problems remain though, please excuse the awkward looking direct export from my org notes (or see the screenshot at the bottom of my comment):
[[file:../../../../../../../../pages/outstanding issues with logseq and org-roam interoperability .org][outstanding issues with logseq and org-roam interoperability ]]
org-roam
how_to_get_logseq_and_org_roam_working_together_to_use_logseq_s_awesome_android_app.org
logseq
logseq bugs that prevent me from depending on it.org
If that's too tough to parse, here is a screenshot:
Update from my side, I've kinda given up on trying to fix it (shameful, but true 😞), as it seems more complicated than I thought to be using id's, since a lot of loqseq depends on names. I'm not super familiar with Clojure, so everything moves slow (today was the last straw when the dev build stopped working for an unknown reason).
Personally, I don't need Loqseq anymore on mobile as I found a way to publish the org-roam files online, and want to invest my time in building a memex which kinda supersedes loqseq's purpose.
I gave up a while ago as well and have since moved away from logseq. I think what I was looking for was a fully featured org roam in emacs on mobile that integrates with my existing emacs configuration.
Of course logseq could never really be that (nor should I really expect anything except emacs to be that). And I don't fault it for that. It's a fully capable alternative to org roam in emacs in its own right.
For others looking for the same thing as I, I ended up hosting an ssh server at home with my emacs configuration that I use Blink on ios to access remotely. Emacs with my thumbs is interesting to say the least but i've gotten used to it with the benefit of having my custom configuration of emacs at my fingertips (thumbtips?) on my iphone.
@venikx @cartwmic I have the same reasons for being interested in this issue. Ultimately, I ended up using hugo to publish my org-roam as a searchable website. Ideally, I'd have a collaborative interface so my colleagues and I can organize work together, but for now a git repo will have to do. Feel free to reach out via e-mail if you'd like to discuss such solutions further.
Are you still encountering this issue in the latest release?
I can confirm that with 0.8.14 the graph still doesn't work with org-id links.
I can't reproduce this on 0.9.5 with the provided org-id format (but with a ref id created in Logseq). It just work as expected and the link is treated as a block ref.
@benide @ParetoOptimalDev @dmitrienka @chrischen3121 @gonfc can you confirm?
As of 0.9.6, these kinds of links still don't show up as backlinks/linked references nor do they show up in the graph.
Describe the bug Seems to be very similar to #696 Logseq won't follow the links with
ID
which are generated by org-roam v2 in Emacs.To Reproduce first.org
second.org
Expected behavior From the
first.org
I'd expect to click on808
and go to the corresponding file.Screenshots Attached is the screenshot - seems like Logseq sees the
808
as a link, but won't follow on click.Desktop (please complete the following information):