I was wondering why users are forced to have everything in bullet point format. I am aware this has been asked again, but hiding the bullet points is the only fix. This doesn’t really make much sense because in the real world people use a variety of software and if they don’t have Logseq then my MD files will look horrible because of all the bulleted text. Do the developers want the files written with Logseq to look so non-standard?
To fix this it would maybe make sense to have document mode not add bullet points. Please consider this as it is the biggest thing that makes Logseq not the best open source note taking software of this type.
I understand all of your points but it still doesn’t change the fact that I can’t share my notes without them looking very weird because of all of the bullet points I didn’t use. Even a good PDF exporter that preserves links would be a good addition (I’m using the plugin but it’s not very good). Obsidian which is arguably Logseq’s biggest competitor in this space has very good MD support and doesn’t use auto-inserted bullet points.
If the program edits MD…is it not an MD editor by default? If you don’t consider it an MD editor then it means you consider the files to be Logseq-specific which makes this whole thing even worse because user are getting boxed in to using your FOSS software. I understand it’s the right tool for each job but it sounds like Logseq wants to be the only tool for the job. No one wants to share MD or PDF documents that have so many bullet points. It just doesn’t look very human. Even your answer is difficult to read and follow.
This account of polarization does not reflect the reality that there are much intermediate ground between an open standard (standard markdown, in this case) and a proprietary one. While it’s true that Logseq files do not look pretty in most other editors, and some improvement in this aspect has long been desired, you are free to use those editors to convert Logseq syntax into something else you prefer (e.g. convert an outline structure into a heading structure).
I agree with you fully on this. Outliners are as great for thinking as they are horrible for reading.
I’m going to write in paragraphs for your sake. If you understood my points, it means that you got your answer, but simply don’t like it. I understand your own points as well (other people have been making them from time to time), but this doesn’t change the essence of the disagreement.
Logseq is not a document editor and most probably will never become one. Logseq is not an open-source Obsidian, was not developed as an Obsidian competitor and, judging by the coming database version, will never become one. The said version is also a proof that, although native support for multiple formats is nice, it is not realistic, as markdown becomes secondary and org-mode is almost dropped. Logseq is not designed around markdown, it simply uses it as a convenient storage, but trying to hide it whenever possible. If you use Logseq-specific features irrelevant to markdown, you get boxed into Logseq. The same is true with every software.
Logseq is a block-based outliner. This has always been fundamental to its nature. If you have difficulties appreciating and even reading outlined content, you are definitely using the wrong application. Just because some of its features are attractive to you, it doesn’t change the previous fact. Many other people praise Logseq for this approach and they are as much humans as you are. There is nothing fundamentally inhuman in structuring texts in different ways. Many people care about the structure much more than about the text itself. Apparently, their workflows are very different than yours.
You are fully entitled to your preferences and particular needs. And there are many like you. But this doesn’t oblige any software out there to adapt. You are the one to adapt, like all of us. Otherwise, you can fund someone to develop the software of your dreams for your own usage. Or go to Obsidian and beg them to go open-source. Or fund someone to improve the exporters or develop new better ones etc., though these will get improved in the future anyway. So you have some choices. But blaming Logseq for its very nature and its basic design choices, it won’t lead you anywhere. For sure Logseq could have implemented those in a better way, but they would remain the same choices.
I have gotten used to the aesthetics and rather consider logseq’s approach functionally superior for longform as well: the dashes/bullets are new paragraph indicators, and ease differentiating between line breaks and paragraph breaks.
Thanks for your reply! I believe it would be very beneficial for readability, interoperability and compatibility for Logseq to have certain settings to change some of the aspects I have outlined. I understand that some things may go against its mission statement, but it still does not remove it from the ocean of note-taking and outlining apps. It is very important, especially as a FOSS, to be able to share its edited files seemlessly with other editors, to promote collaboration and would therefore bring more users in.
I forgot to add that AT LEAST there should be the ability to change the exported style and format for the reasons I mentioned above.
No need for the sass! But thank you for your reply ! Your initial answer was difficult to follow unfortunately and I’m only going to spend a certain amount deciphering an answer posted in outline form. Apologies if I caused any frustration.
No software can be taken out of context from the space of which it inhabits. Other note-taking software exist, and by having Logseq not abiding, by doing its own thing with formatting in such a way, it limits its readability, interoperability and compatibility. In my opinion these are arguements that are very valid for not using Logseq. I understand I can simply not use it (you mentioned some other strange solutions) but I’m not posting on the forum because I believe I am entitled to a change. I posted because I care about the software and these limitations I believe are holding it back. You have mentioned others mentioned these issues as well so why are the developers so stubborn in their own vision that they partially ignore their user base’s needs?
At the end of the day, forcing people to use the software’s “style” and “format” hinder it long term. It is important in an ever growing FOSS world to promote compatibility so that everything can flourish as free and open source. I mentioned in another comment that there should at least be a way of exporting into more shareable/readable formats, which I believe is not an outrageous request.
Just to conclude I want to analyse some statements on the Logseq repo:
“A privacy-first, open-source platform for knowledge management and collaboration”
Collaboration through Logseq? Or just sharing the files? Should I be sharing files with people that can only read an outline structure (based on what you’re saying)? If more document style notes are not encouraged in any way (a partial implementation exists with td) then isn’t that limiting for collaboration? And we are assuming other non-Logseq collaborators won’t get annoyed by having the notes sent to them like this:
Should I have “Test two” in another file to force an atomic note structure? Should I then send them two files instead of one central file?
“… support for multiple file formats, including Markdown and Org-mode…”
Maybe have an asterisk there that mentions how Logseq has its own style of Markdown and that viewing the files in other editors completely messes up the structure?
I hope what I’m saying is more clear after my post, and I really respect your passion for your mission statement, but by taking a step back it’s very obvious that some of Logseq’s approaches don’t really make sense other than just convenience.
Yes I definitely agree that it forces a sense of organisation when taking notes. I do like that but it definitely forces it on the user by automatically adding bullet points to everything. I’m more talking about how the files look exported or in other editors. I believe that this limits readability, interoperability, compatibility, and collaboration when a Logseq user attempts to collaborate with a non-Logseq user. For example there should be a setting where you can select where bullet points should start based on the Heading/Text level. I analysed my thoughts more in another reply if you would like to know more!
Thank you for your feedback. Your frustration may resonate with many users, but your reasoning reveals some deep misunderstandings and sometimes plain ignorance about the software in question (i.e. Logseq), its real user base (i.e. thousands of users), the actual context (i.e. knowledge management), the involved standards etc., no matter some valid questions (e.g. on export, collaboration etc.) A proper answer should begin from the basics, but I don’t personally have the time for that, sorry. If you are still interested in Logseq, should begin making questions about how other people use it, long before bothering with how it could get improved.
My short and final answer on this topic is that, although a beta software like Logseq has plenty of weaknesses, the particular issue that you complain about is actually one of its strongest features, which the average Logseq user describes as more useful to them than any other approach available at this time. For that reason, I heavily doubt that such feedback will have any impact on Logseq’s future.
Oh damn. No I didn’t actually. Thank you for this!
Edit: Need to change the extension to .md at each export. I’m not sure why there isn’t a .md or PDF option by default…I probably need to write my own plugin or script to do this type of exporting then.
I do believe you completely ignored my points regarding readability, interoperability and compatibility. You seem to be contempt with Logseq doing its own thing and preventing 100% collaboration between Logseq and Non-Logseq users. That’s obviously fine because it’s not my software and I hope these issues don’t become obstacles for the future of the software. Thank you for your time!
I think you both have valid points.
For me it looks like this:
Logseq outlining is great and also readable inside logseq and thats the main purpose.
The markdown files are not meant for direct sharing, they are a way to store Logseq content
To share content with other people, or reuse it in other tools, we indeed need better support. Right now it is very basic. A much better MD and PDF export is needed. Latest when the storage changes to a Database, we need this anyway.
This never occurred to me. I use Logseq because it’s an amazing note writing and KM tool. I used it to build 3 different long-form papers last semester. I switched from Obsidian (and many more before that) because Logseq is the first note writing tool that helps me capture knowledge, not just notes.
The thing is that Logseq automatically converts a file you open with it to its compatible MD format, i.e. adds bullets to EVERY line. That’s just silly and shouldn’t happen by default.
I didn’t write long form. I built them. I used Logseq to create chunks of thoughts - some were full paragraphs, and some were snippets used to build paragraphs. I then used all my chunks, organized under the various points of my outline to build (assemble) the actual paper.
I “wrote” the paper using conventional word processing software, but the writing was probably 90% copy & paste from Logseq.
! Your initial answer was difficult to follow unfortunately and I’m only going to spend a certain amount deciphering an answer posted in outline form. Apologies if I caused any frustration.
