Give higher priority to fixing `#+prop` as properties are central to logseq

Feedback
1

This post is originally titled “abandon the #+customprop unique to logseq”

Cross-posted from: org-mode property syntax can make app unusable (Mac + iOS) · Issue #7251 · logseq/logseq · GitHub

I want to suggest against teaching users this syntax or even supporting it. As it currently stands, even for a “logseq org” user there is no benefit to using #+customprop over :: . Both are not recognized by org-mode. #+customprop may look like org-mode but visual resemblance serves no purpose. #+ is (1) less convenient to type, (2) annoyingly triggers tag-completion pop-up, sometimes creating pages in the way, and (3) does not support the property autocompletion of :: .

I’d suggest

  • either teach everyone to use double colon (not only is it advantageous in the 3 above-mentioned areas, but it’s at least also used in roam and obsidian; where else is #+customprop used? not even emacs) ; this way, there will also be fewer bugs related to #+customprop, and it will be easier, for logseq team as well as plugin creators, to develop new features around properties
  • or make it easier for org users to input property drawers, clarify in the documentation about the difference between a keyword (such as #+title ) and a custom property (emphasis added), and if resources permit, work on feature parity (autocomplete).

off-topic rant:
I took logseq as an opportunity to onboard myself with emacs. I learned the wrong thing because logseq gave me the wrong idea, until some time after I realized something was off. Logseq may not care about interoperability with org-mode because they compete in the same space, but file-based and open format are part of logseq’s value statement. As of now logseq is bringing chaos into to the established syntax of Org — which I would happily accept if it’s to enable a new feature Org doesn’t support, but it isn’t that. Considering this is how markdown ended up so messy, it doesn’t sit right with me.

2

Now that I think about it, there’s logic behind logseq using #+ for custom properties because all properties are considered keywords in logseq, for example in query you could write {{query (property :customprop value)}}. It’s just unfortunately very buggy (and unfriendly as it triggers the tag creation pop-up). It’s so buggy that it downright doesn’t work apart from the simplest case of page properties.

As such, I changed the post title.

3

Hey,

Could you elaborate on exactly what kind of bugs this introduced for you when using emacs?

Thanks