Logseq <> Org mode compatability

General
1

By request from @tienson on Discord, here comes a thread related to keeping track of development tasks and issues when working with logseq using org mode syntax.

I’ll start with some issues and feature requests I had myself. What I can recall right now anyways!

  1. ID link in block is empty · Issue #695 · logseq/logseq (github.com)
  2. ID-links does not follow the ID when clicked · Issue #696 · logseq/logseq (github.com)

On a personal note, I just want to add that logseq really is an exciting piece of software for those of us both live in the Emacs world and trying to promote the format for interoperability with other tools!

6 Likes
2

And a third issue that I wasn’t allowed to add in the first post since I’m “new” in the forum! :smiley:

  1. Allow links to ID’s that are not UUID · Issue #698 · logseq/logseq (github.com)
1 Like
3

  • parsing inactive org-mode timestamps

  • @tienson mentioned that created_at property will live outside files in the database after the refactoring… imo there is a lot of value at having some property reflecting when the note was created in org-mode, this gives a lot of context.
    Wonder if it would be possible to optionally allow to duplicate created_at in org-mode property as well? If yes, maybe we could as well store it as a native org-mode timestamp in local machine timezone, I think a more standard way of doing it in org-mode is CREATED property: grep.app | code search

3 Likes
4

The created_at property will live inside the block content for the existing file-based version, but it’ll be stored outside the block content for the database-only version.
The CREATED property looks great.

2 Likes
5

Hi @Whil, This thread is a really good start for making logseq and org-mode work well. I have tried pretty several solutions for using org-mode on mobile, like orgiance, orgmode ios, orgro, logseq outdoes all those tools.

  • Support more in-buffer (maybe in-file in logseq?) settings[1], and headline property settings.
    An example: ‘#+STARTUP:’ could deal with the initial visibility of the outline, and a following property will control the initial visibility of a specific headline[2] when you open the file.
    * Orgmode Headline
  :PROPERTIES:
  :VISIBILITY: children
  :END:
6
  • LogBook support.[3]
    In logseq, once the task state of a headline scheduled as <2021-05-07 Fri 8:00 .+1d> got changed, the state metadata will be stored in the headline block as plain text. I use this feature to track my habit, as well as in org-mode[4] , which is working pretty well. However, since every single state change metadata got stored, the block is getting longer and longer.
    In org-mode, those metadatas could be stored in a LOGBOOK drawer, and the drawer can be folded. The block will stay clean if logseq can support this feature,
    * Org-mode
  :LOGBOOK:
  - TODO -> DONE [2021-05-07 08:46:04]
  - TODO -> DONE [2021-05-07 09:44:34]
  - TODO -> DONE [2021-05-07 09:44:36]
  - TODO -> DONE [2021-05-08 18:31:33]
  :END:
2 Likes
7
1 Like
8

Update on the ID-link issues mentioned at the top of this post. Both issues are fixed in version 0.2!

Trying to import some more files with ID-links however led to another issue, albeit a small one. The issue is that file-level property blocks now prevents parsing of the TITLE keyword. Maybe due to a requirement in logseq parser that a TITLE-keyword needs to be the first line of a file?

Anyhow, created a new bug-report for that so it can be tracked and maybe also fixed! :smiley:

1 Like