General feedback on a full month in Logseq

[SonarMonkey]

The Good

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:

The right sidebar

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.

The continuous-scroll journal

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.

Embedded backlinks

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.

The default experience

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?)

The default theme

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.

The sync

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.

The Slightly Less Good

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”.

Properties

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.

Links vs. Block Refs

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:

1. Supports a fair bit of .org syntax and functionality
2. 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.

Flashcards

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.

At the End of the Day

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.

[Siferiax]

One thing I don’t really understand of this kind of feedback is the want to work on plain text, but also have advanced features but then complain that advanced features make the plain text no longer plain text?

I mean I get the desire, but you cannot expect an app to fully operate on text files without the need of adding information to those text files in order to function in the advanced ways that it does.

Right now Logseq has no internal storage outside of caching what is in the plain files and building an in memory database from there.
So without the meta-data in the files Logseq would not function.

As for properties specifically they are being re-designed (at least for the DB-version as far as I understand)

So yeah I understand it may be frustrating, but one cannot eat their cake and have it too.
Though for some possible solutions I know @FlorianF is very keen on getting to as much universal use out of Logseq .MD files (making them readable elsewhere by leveraging some markdown magic)

[alex0]

In my opinion something can be done to preserve Markdown syntax a bit:

1. Use 5 or 6-long alphanumeric codes for block IDs instead of those very long UUIDs
2. An idea for a more standard-Markdown property syntax
3. Use ```logseq-query (i.e. multiline codeblocks) to delimit advanced queries

There is also Djot that is sort of Markdown 2.0 and some syntax could be adopted from it.

[SonarMonkey]

Yeah, I understand what you’re saying here.

However, there are implementations that enable most, if not all of Logseq’s advanced features without altering the plain text nature of the files.

For example, zk supports templating, tagging, WikiLinks or plain markdown links (and custom link formats), advanced search+filter // queries, interactive fuzzy full-text search, YAML frontmatter, and backlinks. It can serve most of these capabilities to any LSP-compatible editor, and can be configured to use completely pure markdown.

Even Obsidian (without plugins, at least) is very respectful of plain markdown, and by turning off WikiLinks still enables the majority of Logseq’s functionality in what seems to be fully plain markdown.

On the .org side of things, I mean… Most of these things are just outright possible in regular Emacs org-mode, not to mention org-roam.

I guess the core of what doesn’t gel with me comes down to this:

• Logseq supports both markdown and org.
• It specifically says on the main Logseq wesbite “Markdown Files - Open your notes in other tools”
• All of the custom stuff Logseq inserts into its markdown and org causes compatibility issues with most other editors that edit markdown and org respectively.
• All of the custom stuff Logseq inserts into its markdown and org seems pretty possible in plain org syntax.

This is not to flame any of the design choices, internal philosophy, or marketing copy on the part of Logseq, but just to highlight the issue I’m personally running into. It just feels to me that there’s some conflict between the “future proof” and markdown-first nature at the core, and what is actually being saved to my drives. The examples of other tools I’ve mentioned have overlapping philosophies and terminology, but unlike Logseq feel much closer to preserving the syntax they support.

But again - I know the project is young, I know things are changing, and holding any open source projects to the standards or concepts of others is unfair. There’s a lot to like, and it seems to work for a lot of people. Hell, most of it works for me. The qualms I have feel avoidable, but I’m also just one person, and a relative outsider.

[Siferiax]

@SonarMonkey

For example, zk supports templating, tagging, WikiLinks or plain markdown links (and custom link formats), advanced search+filter // queries, interactive fuzzy full-text search, YAML frontmatter, and backlinks.

I’m just lifting this one out as I don’t feel like exploring all the apps you mentioned haha!

• Templating
  • As I understand from the GitHub one would need a templates.md file to house the templates you want to use at the time of file creation
  • I feel Logseq use of templates is more universal
    • I can define a template anywhere, but I myself use a templates.md for it as well
    • I can use a template at any time, whether that is at the start of a new page or on a new block in my journal.
    • This is then a discussion on property usage, as template:: <name> is all the template syntax.
• Tagging
  • Logseq supports #hashtags just as zk seems to do.
  • In Logseq this is the same as the [[ ]] syntax, just visually distinct.
  • Logseq supports plain markdown links as [ ]( ) as well.
• Filtering & queries
  • Correct me if I’m wrong / not understanding the tool based solely on documentation alone.
  • It seems this works on the command line only?
  • Does it support having a page only consisting of queries of which the results can be edited in place?
    • This is how I use queries as my main method of workflow. A startpage with queries to get the relevant data from my graph (mainly journal, but other places as well) that I can then edit
  • yes Logseq will write the query syntax to file. But it needs to save it somewhere…
  • Logseq doesn’t support the advanced filtering capabilities as a search though. But I believe that is getting worked on.
    • which is to say I distinguish that from queries as being a different use case.
• It seems to me zk uses config like files a lot to get its functionality
  • I like that Logseq offers a lot of functionality in file without having to edit a separate file first
  • There are pros and cons to both sides here
• Something like more standard frontmatter would be nice. Though as said Logseq is probably changing properties anyway.

I know a lot of people complain that Logseq writes collapsed:: true to file.
However when I look at Obsidian I see the trade off. When I create a file there with some bullets and then collapse those, sync my vault (through Git, just as I do Logseq) and open the file on another device that collapsed state is lost.
This is the advantage in file meta data bring i.m.o.
And this is of course a very simple one, but one I rely on nonetheless.
I can’t speak more on Obsidian, because I only use it for long form writing and I can’t really find advanced comparable features on the mobile phone app.
What I do know is it “supports” YAML frontmatter as text between — gets hidden in view mode and gets a different style in edit mode. But I don’t know if it can actually use that frontmatter in the way Logseq uses page properties.

@SonarMonkey

All of the custom stuff Logseq inserts into its markdown and org seems pretty possible in plain org syntax.

Maybe, but I disagree Logseq should therefore use org syntax for that.
Or better said, from a markdown perspective that doesn’t change anything I feel.
I would still have meta-data in my files that a markdown editor doesn’t understand.
Maybe it looks better? Idk. I don’t know org.

You don’t really give more syntax examples outside properties, block/page refs and flashcards.
The last I deem very specialized functionality, so I doubt there’s a way around it. I don’t use it personally anyway.
I think I touched on properties enough. You said yourself that [[ ]] syntax is more universal (Obsidian uses it as well for example) and #hashtags can be used in a similar way.
So that only leaves block references. Something that is a debated topic (the UUID that is) and also seem pretty unique to Logseq? But correct me if I’m wrong there.
There are a number of feature requests in terms of the UUID usage and allowing different ways to address blocks.
And I agree it isn’t the most pretty. But for me and my situation it is not a deal breaker. The data is still there after all. Should I wish to move away from Logseq I can replace those ID references if needed.

@SonarMonkey

It specifically says on the main Logseq wesbite “Markdown Files - Open your notes in other tools”

I disagree with the assertion you should want this while also using Logseq, but I understand the need/want for it.

@SonarMonkey

All of the custom stuff Logseq inserts into its markdown and org seems pretty possible in plain org syntax.

I don’t know if this is true. As you stated yourself for example there is no alternative to block refs.

As I look at my graph only 2 things cause problems for my readability outside Logseq

1. Block refs / block embeds
2. Queries
   The third category might be flashcards, but I don’t use those.
   Both block refs and queries don’t have an org alternative.

@SonarMonkey

This is not to flame any of the design choices, internal philosophy, or marketing copy on the part of Logseq, but just to highlight the issue I’m personally running into.

Totally! I like this discussion of features. I found Logseq and transitioned to it from a physical bullet journal, goodnotes and a tracking app that I couldn’t get my data out in a usable format.
So I have very little knowledge on other apps, and therefore I like these discussions.

@SonarMonkey

It just feels to me that there’s some conflict between the “future proof” and markdown-first nature at the core, and what is actually being saved to my drives.

I can understand that. I feel the future proof / markdown first argument is mainly useful in the context of getting your data back out and less so in the context of using Logseq.
At least that’s how I feel about it. My data is accessible at any time, stored in files that a plain text editor can open. From there I can do with it what I will if I move away from Logseq.
Sure they may need some editing, but unlike the above mentioned tracking app, at least all the raw data is in there.
So I agree that during use of Logseq the files are not suited for the outside world in a way maybe Obsidian file for example are. Though at least we are able to get the raw data out of Logseq, which is what matters to me personally.

Oh gee… That was a long post on my phone so already sorry for any errors or weird sentences or repeated points… I have no idea what I wrote when I started this type up.
And I don’t mean to attack btw, I just like sharing viewpoints/make counter points. And I look forward to any counter arguments you may bring to the table!

[FlorianF]

@alex0

Use 5 or 6-long alphanumeric codes for block IDs instead of those very long UUIDs

I’d rather have a DateTime-UniqueDifferentiator as ID so I can infer the file the block is in even if Markdown doesn’t have an anchor standard syntax…

@SonarMonkey

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.

I support this fully. This is about the only part of Logseq-specific code that I am sticking with becuase it offers enough value to not depart from it. But I will, at some point, have a script to transform [[#WikiLink]] into proper local file relative link.

@SonarMonkey

And editing markdown created from Logseq in other editors is… messy. Many features represent stark departures from “plain markdown”.

Since I have found a way to have both Logseq Properties to use inside Logseq and have them rendered in Markdown as Multi-Line Link Title I am a happy camper. There are posts where I explain that, i think. The only downside is that I can’t use Headings (##) in blocks because of the hack to enclose Properties in Markdown).

I am heavily using Custom Commands as a form of Text Expanding and will, at some point, transfer all to a proper Text Expander like Espanso, so I can have such handy expanding texts in other apps as well.

As a quick conclusion, as long as I can enclose whatever properties, scheduled times, deadlines, etc that Logseq crams in between the Block Title an the first Line after a Soft-Break in whatever Markdown Syntax as to make sense to both Logseq and Markdown, I will stay with Logseq.

[SonarMonkey]

Thanks for the reply! You definitely brought up some things I wasn’t really considering, and a few things I should have maybe been more specific about.

@Siferiax

• As I understand from the GitHub one would need a templates.md file to house the templates you want to use at the time of file creation
• I feel Logseq use of templates is more universal
  • I can define a template anywhere, but I myself use a templates.md for it as well
  • I can use a template at any time, whether that is at the start of a new page or on a new block in my journal.
  • This is then a discussion on property usage, as template:: <name> is all the template syntax.

You’re definitely right that Logseq templates are more flexible because they can exist (and be instantiated) anywhere. You’re also correct that zk (and org-roam, and obsidian) need template-specific files to exist. Obsidian’s implementation supports inserting templates into existing files, but zk does not. These both have limitations that Logseq doesn’t, and in general there is a lot to appreciate about how Logseq handles templates.

@Siferiax

• Correct me if I’m wrong / not understanding the tool based solely on documentation alone.
• It seems this works on the command line only?
• Does it support having a page only consisting of queries of which the results can be edited in place?
• This is how I use queries as my main method of workflow. A startpage with queries to get the relevant data from my graph (mainly journal, but other places as well) that I can then edit
• yes Logseq will write the query syntax to file. But it needs to save it somewhere…
• Logseq doesn’t support the advanced filtering capabilities as a search though. But I believe that is getting worked on.
• which is to say I distinguish that from queries as being a different use case.

Yes, this only works from the command line, and cannot be embedded in pages. To get Logseq-adjacent functionality in zk, one would: 1) define the query to an alias in the config file, or write it out as a one-off command in the command line, 2) run that interactively in a console window alongside, or use the LSP/nvim integration to run the equivalent command from inside a compatible editor. So yes, the query does need to be saved somewhere regardless, and both Logseq and zk support doing this in the config file instead of a given page. The ability to embed queries in a page is definitely very cool, especially since block editing can happen directly from inside the query display in Logseq. This is, as far as I am aware, unique to Logseq.

@Siferiax

• It seems to me zk uses config like files a lot to get its functionality
  • I like that Logseq offers a lot of functionality in file without having to edit a separate file first
  • There are pros and cons to both sides here

Absolutely. Logseq can honestly do quite a lot in the config file as well, but the fact that it can be embedded in pages is a strength as much as it is a departure from plaintext. Personally, I appreciate some separation between things that are text functionalities, vs things that are editor/program functionalities, so it’s easy to see why I like the config-based approach for the fancy stuff. However, I see that there’s really nothing stopping me from separating files containing Logseq-specific functionality from what I consider my “permanent” files that I want to largely be plaintext.

@Siferiax

What I do know is it “supports” YAML frontmatter as text between — gets hidden in view mode and gets a different style in edit mode. But I don’t know if it can actually use that frontmatter in the way Logseq uses page properties.

As far as I know, Obsidian supports actually using the frontmatter for built-in properties it already supports, but wouldn’t really do anything with properties it doesn’t. So, if I define tags or page aliases in the frontmatter, it would treat them as such, just like Logseq. Unlike Logseq, it would not do any handling of custom properties.

@Siferiax

@SonarMonkey

All of the custom stuff Logseq inserts into its markdown and org seems pretty possible in plain org syntax.

Maybe, but I disagree Logseq should therefore use org syntax for that.
Or better said, from a markdown perspective that doesn’t change anything I feel.
I would still have meta-data in my files that a markdown editor doesn’t understand.
Maybe it looks better? Idk. I don’t know org.

You don’t really give more syntax examples outside properties, block/page refs and flashcards.
The last I deem very specialized functionality, so I doubt there’s a way around it. I don’t use it personally anyway.
I think I touched on properties enough. You said yourself that [[ ]] syntax is more universal (Obsidian uses it as well for example) and #hashtags can be used in a similar way.
So that only leaves block references. Something that is a debated topic (the UUID that is) and also seem pretty unique to Logseq? But correct me if I’m wrong there.
There are a number of feature requests in terms of the UUID usage and allowing different ways to address blocks.

Yeah, this is where I really should have been much more specific. In .org syntax, one can do property drawers, like so:

:PROPERTIES:
:title: Some Concept or Page
:id: 092847-random_whatever
:aliases: Synonomous Concept
:folded: true
:tags: tag1, tag2, tag3, card
:flashcards_last_review: <2023-08-11>
:hotel: california
:END:

With these drawers, if they exist at the top of a file, they define file properties (which get inherited by stuff in the page), but if they exist below some heading (defined like * Top-Level Heading, ** Equivalent to H2 in .md) then they define properties for that heading and all of it’s children through inheritance. The cool thing is that it doesn’t really matter if org-mode knows what these properties are or not, they’re all just properties, and can be queried as such.

For example, you can use links that take advantage of this - instead of [[Some Concept or Page]], you can do [[id:092847-random_whatever]] and then either have your program understand and render what that id actually goes to, or do link description like [[092847-random_whatever][Some Concept or Page]]. This way, block links and page links are exactly the same, and do not break if you file a block somewhere else or turn it into it’s own page.

But custom link types and property handlers can be defined just as easily - the flashcard metadata, tags, additional to-do properties, icons, etc.

@Siferiax

Maybe, but I disagree Logseq should therefore use org syntax for that.

Suggesting to use org syntax in markdown files is certainly kind of silly. The reason I bring it up at all is that at least then it would be an existing, standardized syntax that external parsers could understand. Not that other editors would understand both at the same time, but, yeah. I specifically suggest org because Logseq’s parser understands both already, and there’s a lot of tooling, code, and thought around org. But no, it does not really change anything re: inserting random other stuff into your markdown.

@Siferiax

@SonarMonkey

All of the custom stuff Logseq inserts into its markdown and org seems pretty possible in plain org syntax.

I don’t know if this is true. As you stated yourself for example there is no alternative to block refs.

As I look at my graph only 2 things cause problems for my readability outside Logseq

1. Block refs / block embeds
2. Queries
   The third category might be flashcards, but I don’t use those.
   Both block refs and queries don’t have an org alternative.

I should have specified there’s no easy alternative in plain markdown, but there is a way to do this by default in org, with those ID links I mentioned. If Logseq really still wanted block refs to be different from page refs, there could be a secondary :block_id: property and Logseq could define a custom link type. ID Links do exist in plain org, though, so I misspoke - External Links (The Org Manual)

@Siferiax

I can understand that. I feel the future proof / markdown first argument is mainly useful in the context of getting your data back out and less so in the context of using Logseq.
At least that’s how I feel about it. My data is accessible at any time, stored in files that a plain text editor can open. From there I can do with it what I will if I move away from Logseq.
Sure they may need some editing, but unlike the above mentioned tracking app, at least all the raw data is in there.
So I agree that during use of Logseq the files are not suited for the outside world in a way maybe Obsidian file for example are. Though at least we are able to get the raw data out of Logseq, which is what matters to me personally.

And yeah, absolutely. It seems like this is Logseq’s take on the future-proof markdown concept, and I don’t think there’s anything inherently wrong with that.

Sorry if I missed anything, I’m running out of time right now but I will probably make a further follow-up to this thread. I appreciate everyone’s discussion and engagement!

[mentaloid]

@SonarMonkey

there’s really nothing stopping me from separating files containing Logseq-specific functionality from what I consider my “permanent” files that I want to largely be plaintext

In my opinion, this is the essence.

[alex0]

@SonarMonkey

However, I see that there’s really nothing stopping me from separating files containing Logseq-specific functionality from what I consider my “permanent” files that I want to largely be plaintext.

For this purpose, you may want to check the contextual sidebar: I store most of my queries there and they refers to the current page in the main view. This way I reuse the same queries and I store them in a single file instead of polluting content files with non-Markdown syntax.

[Siferiax]

@SonarMonkey

both Logseq and zk support doing this in the config file instead of a given page

Unfortunately in Logseq’s case this only shows the query at the bottom of today’s journal page. It would be so cool if we could dynamically invoke such a query anywhere! That could add great value. I think this is where the query value of zk is then.

@SonarMonkey

However, I see that there’s really nothing stopping me from separating files containing Logseq-specific functionality from what I consider my “permanent” files that I want to largely be plaintext.

Sure. Until you collapse a block and then you have collapsed:: true in your file
And maybe other cases where the same can happen.

@SonarMonkey

As far as I know, Obsidian supports actually using the frontmatter for built-in properties it already supports, but wouldn’t really do anything with properties it doesn’t.

Ah! Good to know.

@SonarMonkey

In .org syntax, one can do property drawers

Oh! That functionality is pretty cool actually! Something similar for Logseq would indeed be nice.

And no worries about missing something, I said so much I don’t even remember everything you could potentially reply to!
I appreciate all the insight you shared.