Migration to Obsidian

General
1

So I just finished my migration to Obsidian, and I can report back that people who still talk about Markdown compatibility are clueless armchair theoreticians. Logseq’s files are so dependent on Logseq that to keep calling them Markdown is, at best, misleading. Personally I’d use much stronger, uglier words.

Let’s remember that the whole point of Markdown is that it can be read/written in plain text mode, while adding just enough markup and structure that it can be rendered into something prettier. In contrast, Markdown that is uglified so that it is hard to read as plain text just so that it works as a bad DB is the worst of both worlds.

So, turns out that Obsidian uses rather pretty clean Markdown! So this is the summary of the cleanup I had to do from Logseq:

  • It’s all a sea of files - no directories. Logseq people talk a lot about how you should think of stuff as blocks, not pages, and that kinda makes sense (though it doesn’t explain why there is no freaking folder functionality for those who actually want it). But the moment you want to publish something, suddenly the block concept evaporates and you’re forced to consider whole pages again.

  • Worse, once you leave Logseq, the whole tags and queries functionality is gone, so you’re left with a sea of unorganized files. It’s Logseq’s way or the highway. Which is understandable! But that is far from the claimed compatibility.

  • You have to translate all tasks from Logseq’s incompatible NOW, DONE, CANCELED, etc. to actual Markown’s - which Obsidian supports and augments while still looking like actual Markdown. (lol, even the forum understands [ ] over NOW)

  • Logseq sprinkles its own stuff like collapsed:: true everywhere, which needs to be deleted manually. Obsidian manages to keep it out of the text.

  • Numbered lists are another standard Markdown feature, but even that is borked by Logseq by turning it into bullets + its own internal property logseq.order-list-type:: number that of course messes up the text

  • Even filenames need cleaning up, because Logseq throws in some gratuituous URL-encoding.

All of this makes to me a good argument for why Logseq should move its backend to a proper DB. But the kicker is, Obsidian manages to keep those clean Markdown files, with pretty much the same functionality as Logseq! Including sync! And I don’t see the reports of data loss in their forums.

I’m thankful that I migrated when I still had less than 100 files, because wow is this eye-opening.
By the way, I tried the export formats offered by Logseq, and they all oscillated between useless and awesomely broken. Try to export in Roam format to have a laugh! The rot is deep.

5 Likes
2

I aggree Logseq doesn’t emphasize Markdown compatibility, far from it. And Markdown is a bad choice for anything database-worthy. If they really wanted, it’s possible to make clean markdown. But Markdown is not created for metadata and Logseq doesn’t want to use clever workarounds to make clean Markdown even with metadata although they clearly use extra data in the Markdown files and still call it Markdown-compatible, which is misleading.

I have managed to avoid exporting anything from Logseq and strived to use the very Markdown files Logseq is using as data structure atm by some clever using of multi-line link titles and don’t consider it any more hack-ish than adding extra, unsupported markdown syntax. If Logseq would support Multi-Line Titles in Markdown Links (as it’s CommonMark standard Markdown) it would even be easier, prettier.

I’m getting this way clean text and still retain the custom properties I create to have structure. I also don’t have any difficulty to write over and over again the syntax that makes this possible because I use Logseq’s text expander (custom commands) with every Note Type i usually enter in the journal so i don’t even have to think about it -as most my notes are atomic and each note has a type that is defined as custom commands.

For TODOs i use unicode characters in inline Markdown Links that look like [🔳]([[TODO]] " #de ") (I actually use many more “#de*” tags to narrow down queries to my needs and use the [:editor/input "" {:last-pattern "<" :backward-pos 37} ] custom command syntax to position the caret right adter “de” (“to” - in my native language) to write at the Note Capture time the exact type - #defacut #deexplorat #desunat etc). This way my notes render ok in both Logseq and markdown (instead of [ ] and [X] ) and I can query for the exact tag. The only thing I loose is the Ctrl+Enter functionality for the TODO, which is replaced by a custom command like <info or <book which then gets me a block template where i achieve much more functionality than the single TODO introduced by Ctrl+Enter.

There are many things one can achieve customizing Logseq if he really cares about the locally-first approach.

I don’t say Markdown is the best format for anything, less a database and even for clear text it’s still in a hard drive that is 0s and 1s and an open source database is about the same from that pov. I would have liked a JSON-based db to be frank, which is still text-based and there are examples of such dbs out there performing very good.

Nevertheless all this discussion is kinda useless as long as the db-version is coming and the bi-directionality will not be a feature of that one.

2 Likes
3

Except all the functionalities enabled by parsing all the files in the graph and storing the structured content in a DB: you can freely embed blocks, pages, check Linked References, block references and query results and edit them live. Obsidian can’t allow editing and it will never be able to provide this functionality without taking the same route as Logseq.

1 Like
4

Except all the functionalities enabled by parsing all the files in the graph and storing the structured content in a DB: you can freely embed blocks, pages, check Linked References, block references and query results and edit them live . Obsidian can’t allow editing […]

I’m not sure how to parse that… so, care to give a concrete example? Because in this past week I’ve been doing much more with Obsidian than I dared before with Logseq, and the only thing I’ve noticed until now is that bullet point drag’n’drop sometimes doesn’t activate (which is tracked in a Github issue in the outliner plugin - it’s so refreshing to see that forums, issues and docs keep each other up-to-date!)

5

?? You can edit blocks when you are not in their page, as I said, in Linked References, query results and embedded pages/blocks. It’s literally the main Logseq feature.

6

So you meant block transclusion? That is neat, sure… but to me it never graduated to a real tool. The logseq.com page doesn’t highlight it that much, are you sure it’s “literally the main Logseq feature”?

The only pseudo-transclusion I kept using after a few months was task queries, and those of course also exist in Obsidian, and of course I can edit them from the query results. It is slightly clunkier (1 click for status changes, 2 clicks for actual editing, oh my), but in exchange it’s consistent: the result gets reflected in the Markdown file as one would expect, so it is immediately shareable. And that was the whole point of Markdown storage, remember?

Alas, as already said, transclusion is one example of why Logseq’s Markdown backend was dubious, if not doomed from the start.

Would it be nice if Obsidian did actual transclusion? Sure. Would I sacrifice Markdown compatibility for it? Probably, as long as there is good, guaranteed access to the data. Would I risk data loss? God no.

7

So you used Logseq as a simple wiki this whole time and didn’t get the main workflow at all, that is the same of Roam Research… then just use Obsidian but be aware that Logseq is a totally different thing.

8

No, not as a simple wiki, because wikis don’t lose data.

As I said, now that I see that my data seems to be safe, I can experiment more freely, so maybe now I would find a use for transclusion. Or maybe not and I’d still find it to be just a talking point for productivity youtubers. I guess we’ll never know.

Or maybe Logseq at some point will grow a reliable backend and I’ll try it again. I’d have to see how to make it understand this newfangled organizational tool called “folders”, but oh well, we’ll cross that bridge when we get there, right?

1 Like
9

There is this proprietary online app called Roam Research that combined an outliner with wikilinks to populate Linked References sections and query results in a smart way: the user just need to type their notes, making references and logically indent to have them automatically structured and queryable.

Logseq reimplemented that approach as a local file-based application. If you are not appreciating this then you should definitely use Obsidian, not Logseq. It may be a niche approach, sure, but some of us use it and don’t need to show it on YouTube or explain to people how to build complex workflows.

10

We’re pretty out of topic, but I’ll bring it back at the end.

I know RR, I started using it because a friend won me over when he showed me a transclusion while explaining some note of his. Tellingly, I remember the transclusion example, not the actual idea he was explaining. In retrospect, that should have been a warning, not an allure - do you want to be remembered because of the quirky tool you use or because of your ideas?

I wasn’t happy with some aspects of RR so I started using Logseq, for management of my incipient PhD and for development of various unfinished blog posts. In these months I used transclusion 2 times. Both times it was a sign of unfinished thought and an impediment for sharing the document. So both times I had to get rid of the transclusion to actually use the ideas. And the result was better for it.

So at this point, from where I sit, transclusion looks like a good way to dump unfinished ideas. It also looks like a warning that you didn’t do the actual work of analyzing/synthesizing information. It was a flashy crutch that made me feel I was progressing even though I was thinking and writing in circles.

And transclusion is mostly unpublishable - particularly in Markdown files! Again, for my literature review that was actually good, because that forced me to step back and decide what was the point that I was trying to publish. But even just sharing text files with my supervisor needed a rethink.

Of course this is just my ~1 year worth of experience with this subject. I bet there are other experiences.

11

So you’re a moderator, and go ahead and mock a user for not understanding how Logseq is a copy of Roam Research? Wow… This is hilarious.

Yes, Logseq is an Outliner like Roam Research, and yes, it has great block reference architecture, but it’s definitely not it’s main workflow for some of us who haven’t come from that world.

I’ve been using it since over a year now, and never really needed what you say is the main workflow, so I guess I’m also using the wrong tool for achieving our goals. I guess all of us should all abandon ship and use Obsidian instead, where moderators don’t bash users for wanting to have a say in the direction their tool of choice takes.

1 Like
12

No, I’m annoyed that in this forum only I have to state the same thing 3 times because people don’t read carefully: I have marked “edit them live” in bold and yet it was ignored.

Logseq is:

  • forcing an indented list structure on every page
  • tagging blocks with wikilinks and hashtags that are in the block or in its parents
  • presenting every page with a big Linked References section populated according to the two previous point
  • you can edit the blocks in Linked References without leaving the current page
  • if you hover a reference you see a popup that allows you to edit the referenced page without leaving the current one
  • you can open single blocks in the sidebar and edit them from there
  • you can embed blocks and pages and edit them (what the other user seems to refer to when saying “I used transclusion only 2 times…”)
  • you can write Simple Queries or Advanced Queries and by default edit the results

and this isn’t the main Logseq workflow?

Logseq is so unstable in handling data because of this, because to implement the above workflow it needs to parse every file and keep their content synced with a DB.

This is not off topic, they are developing the so called DB version exactly to solve all those issues.

If you don’t use Logseq that way you can’t really appreciate it, then really just use Obsidian: because of its “text editor” approach it will always be better at everything except enabling Logseq’s main workflow.

13

Not a “user not understanding how…” but a user praising Obsidian with no reason other than provoking and reading my replies superficially.

The following is OK:

But then:

Notice the part in parenthesis in particular. How isn’t that provoking?

If you think Obsidian is better for you, maybe because you didn’t understand Logseq main workflow in the first place, just use Obsidian, no? Why coming to Logseq forum to say that and make me write 4 replies to explain Logseq main workflow?

14

Are you talking about embedding blocks and pages? Because when you export to Markdown the references are replaced with their content, making Logseq a “framework” to produce standard Markdown files if you want: the export feature can remove indentation, wikilinks parenthesis and hashtags.

But I wasn’t talking about embedding blocks and pages. This is my final attempt: embeddding blocks and pages is a “manual transclusion” but Logseq does “automatic transclusion” all the time, to the point that if you open an empty page that was referenced a lot, you are presented with a big section containing “transcluded blocks” you can edit. Obsidian can’t do this without taking the same route as Logseq and facing the same issues Logseq has.

15

I’ll make one attempt at explaining how I use Logseq without your primary workflow and still find it extremely valuable.

  • I work as Product Manager, and use daily notes to make all my notes, or most of them anyways.
  • The outliner style helps me maintain notes like bullet points, without needing to write paragraphs like Obsidian defaults to.
  • I maintain hashtags and entity (page links) at the primary bullet level, then indent related notes under it. This means that when I click on any of these two items, or go to their “page”, I find all my notes chronologically sequenced and in the main window.
  • I don’t refactor my block references and have mostly never needed to reference them again and again.
  • Logseq functions as a recall engine for me, almost like a bullet journal that I don’t need to manually flip through to get context on a topic over long periods of time.

So help me out here, if you’re so keen to suggest that I am not really using Logseq like it is supposed to, in the above flow, when does block reference make sense and what value will it offer me?

P.S. If someone appreciates a capability in another product and still is spending time “living with” data instability and loss in the product you’re moderating the forums of, it’s likely not in their interest to provoke you. And I don’t think that’s the intention here.

Are you getting provoked? Clearly.
Is that comment provoking? Not really.

16

Then can you explain how is this text relevant when asking me to provide a “concrete example”?

(which is tracked in a Github issue in the outliner plugin - it’s so refreshing to see that forums, issues and docs keep each other up-to-date!)

17

Strange. My other note taking app is Joplin, this uses (the same) dBase from the get-go and is based on Markdown files. Nobody in the Joplin community has ever been worried about the database engine. It can import/export; print; sync, save to pdf, html, jex, raw, frontmatter etc. The back-up plug-on is recently added to the core. It is fast searching with large number of pages. Why worry so much?

1 Like
18

2 things here. If Logseq uses Markdown as storage, why have an “export to Markdown” function at all? It’s a hint that the whole thing is misguided.

But worse, have you tried comparing the “exported” Markdown with the “native Logseq” Markdown? I did! It’s barely changed from Logseq’s normal Markdown; it still keeps all of the metadata that needs to be cleaned up manually, so again calling that “standard Markdown” is misleading at best.

FWIW, Obsidian doesn’t “export to Markdown” - why would it?
Sorry that I keep referring to it, but seems to me that it’s the only way to keep the discussion grounded, instead of going into abstract aspirations of “exporting to standard markdown”. Here’s this other project which not only talks the talk, but walks the walk!

But Obsidian does present you with the same! The only thing it doesn’t do is the “you can edit” part. - you need to click on it first. And hey, I can see how that would be convenient, of course! But I don’t see how it is a justification for failing to have the real Markdown that was advertised.

I’ll insist: Obsidian advertises Markdown storage, and they push it in amazing ways, but stay true to what was advertised. Whether md storage is a good idea is another thing, but they are keeping a promise. I can respect that.

Meanwhile, Logseq makes the same promise, and then fails at it in multiple compounding ways.

I agree. And I can give you a more fundamental example: since the Obsidian ecosystem is so focused on keeping all the data in the Markdown files, while keeping them clean, that poses fundamental problems like how to store metadata for a task. E.g., how to store the creation and completed dates of a task without turning it into an uncomfortable block of text? That is the problem I am dealing with right now.

Logseq deals with that by hiding all its stuff in the Markdown and hoping that you won’t look at it. It gives you a ton of functionality, but it fundamentally breaks the Markdown promise. How to fix that? Move to a DB, decouple it from Markdown. So it’s good that the devs decided to move to a DB. Hopefully then that will improve everything, from APIs to reliability to actual Markdown export.

But until then, just like Obsidian deserves praise for sticking to the Markdown promise, Logseq deserves to be called out for all the ways it fails at that. Removing the promise is the first step.

19

Let me summarize:
Logseq has more functionality, and potential, than e.g. Obsidian. But to achieve this they break the idea of Markdown-as-storage.
Conversely, Obsidian can’t have Logseq flexibility. This is because they keep the promise of having good Markdown storage.
Those who care about having Markdown-as-storage while having Logseq’s features should make sure to understand what they are asking for. IMO, they don’t.
Having reliable import/export functionality is all that anybody cares for - or do you actually know how is the text read, processed and written by the program? Markdown-as-storage is a distraction.

20

What ever gave you the impression that Logseq would conform to CommonMark specifications? Logseq never advertised or made any statements that it would hold to this standard. This is due to the additional markup required for Losgeq’s internal DB to function and the adoptions they took from org-mode, such as the task states “NOW, DOING, TODO, LATER, WAIT, etc…”. So I get its a negative point for you, but it sounds like you’re holding Logseq to this CommonMark standard when its never made claims to do so, so sure, it sucks, but if its a requirement for you then why not just move to Obsidian and be done?

Do you have a link where this was advertised? Their documentation states they support “most” syntax’s along with the additional markup they’ve added: “Markdown is the most popular format that Logseq supports. Logseq supports most syntaxes including some extended ones.” (source)

Also the editable transclusion does make a significant difference, for instance being able to click and drag a block of text and relocate that content to a different transclusion or the page itself is a must for myself. I tried migrating to Obsidian a few times but I can never fully make the switch due to this.