First, I wanna say that I really like Logseq. All in all, it’s pretty wonderful, and having used Zettlr, org-roam, Obsidian, vim and friends, and zk over the years, it has some stand-out features. In particular:
It’s awesome, out of the box, especially after the most recent update. I often use whatever text-workspace I’m in as auxiliary brainpower, and ideally my working text environment should allow me to hold vast clouds of information all right in front of me. There is something I find deeply intuitive about shift+click or shift+enter to add it to the things I need floated, and the way the different sidebar items can scroll continuously, fold, and unfold is wonderful.
My workdays often generate quite a number of journal entries that house all sorts of information and tasks, and in the context of the “auxiliary brainpower” I mentioned, being able to “think back” to yesterday with a scroll or two is quite nice, and what I will miss most if I leave Logseq.
I know this is not strictly unique to Logseq, but the fact that I can click in to edit backlinked blocks, or drag them around to “re-file” them right from where they’re displayed at the bottom of a given page is awesome. It makes working with information in a non-linear way very easy, which is exactly what systems like Logseq should make possible.
I am very happy that there seems to be a healthy plugin and theme ecosystem for Logseq. It’s a good sign for any open source project, and a lot of people are doing a lot of awesome work. That said, I’m also very happy that I can just use Logseq without screwing around installing add-ons and themes. I’ve been using it as my primary text-thinking working environment for a little while now, and while I’ve played around with a couple plugins I have always been pretty keen on using it stock. (Especially after the new sidebar update. Did I say how much I like the sidebar update?)
I love the default solarized theme - it’s what I already use in several other environments on my computers - and I think it’s neat to see default adoption of a more ergonomic theme in an app one could reasonably need to spend all day staring at.
I know I’ve seen some complaints around here about data loss and the like, but I have not really had any major issues. Occasionally the odd insert of a random empty bullet, or half-duplicating the last block I edited, but no data loss. It’s very cool to have all that information on all my devices so easily. I only ever use the phone app for quick entries into the journal, and for that purpose it’s a really nice convenience.
I still use other tooling to work with all my assortment of markdown (and occasionally .org) files. Particularly, sometimes I am in my terminal environment, where I am very comfortable, and often reach for Helix or Vim to quickly read or edit something. And editing markdown created from Logseq in other editors is… messy. Many features represent stark departures from “plain markdown”.
For whole pages, frontmatter exists (and is supported) but from my reading of the wiki and use of Logseq does not seem to be the default way to do page properties. Maybe I’m missing something, but why not use a more broadly supported methodology like that as the sole or primary implementation of page properties?
I understand the need to embed properties in individual blocks, which markdown has no real way to do. But logseq supports
.org syntax as well, and it feels to me that it might be neater just to simply use
.org syntax where markdown falls short, if the built-in parser can comprehend both.
While [[WikiLinks]] are at least a somewhat more broadly adopted convention, at least among Logseq’s markdown-first contemporaries, the block ref ((UUID)) links are entirely non-standard. The only alternative to WikiLinks right now are
.org-exclusive hard path
file: links, and there is no alternative to block ref links.
Again, maybe I’m missing something, but, if Logseq:
- Supports a fair bit of
.orgsyntax and functionality
- Has no qualms about embedding custom properties right in the file
Why not just use the existing
.org implementation of property drawers across both markdown and org? If that was the case, block refs and page refs could all be the same type of ID link, or even accurately mix ID, Title, and Alias links without custom syntax.
Even if not, I’d love to see a toggle like the org
insert-file-links for markdown, to at least provide the option of using standard
[Page](Page.md) markdown links, since it seems they’re already supported and recognized as backlinks.
Simple page properties are maybe no big deal, but flashcards throw six lines of metadata no other markdown editor knows anything about right into every single block with a
#card tag. I really think a built-in implementation of an SRS is very, very cool, but with it further cluttering what should be externally navigable markdown, it’s hard to convince myself to try to take advantage of it. As it stands, if I wanted to mix flashcards into my general files, “Open Logseq → Navigate to Page → “Export” → Remove Properties → Copy → External Editor → Paste” for a pure markdown editing experience on flashcard-containing files is a lot. This is less of a big deal for me, since my desire to use the flashcard system was for an off-label and experimental use anyway.
I like Logseq. It’s an unbelievably cool project, it does some really wonderful things, and it makes for a fantastic general-purpose nonlinear text workspace. However, I am not keen on some of the departures it makes from “future proof” markdown. For my use-case, this prevents me from using Logseq as much more than a lovely cloud of scratchpads and agendas. I put a lot of work into the writings I store long term, and I store them as close to plaintext markup as I can on purpose.
I want to be very clear that I don’t mean anything negative by my questions and feedback here. I’m not particularly familiar with the code or underlying tools at play, and I understand that 1) Logseq is in beta, and 2) design and implementation decisions are made for complicated reasons. Much love to the devs and all of you here in the community.