If you want something different from what is being requested, it is not helpful to try to argue that your needs should be met over the needs of the people who made that request. It is better to make a new request where your needs can be discussed in a non-confrontational manner and get the support they deserve.
6 Likes
People who do are used to breaking a problem into small parts and solving those first. Good luck with your bloated and fancy requests.
2 Likes
I think y’all should checkout Emacs Org-Mode.
Logseq is great as it provides a low-barrier entry, but you want lots of in-depth features that already work over there. I recommend starting with Doom Emacs plus org-roam as a base, or maybe directly use GitHub - sunnyhasija/Academic-Doom-Emacs-Config: My doom emacs configuration files (I might also develop my own Emacs distribution for such a workflow at some point ^^).
You write your markup, which stays usable in both as Logseq apparently also supports org-mode syntax and you can easily convert over with pandoc, then you can easily edit it (no need to split text up into multiple files with org-mode’s folding and rearrangement shortcuts) and export to PDF, HTML, reveal.js presentation and much more.
PDFs can be created via the TeX engine of your choice, producing much nicer results than any word processor. In fact, I have abandoned all word processors over the last year, ditching their clunky clicking for full text-based formatting 
1 Like
Is there any new progress?
4 Likes
td (document mode) works, but it’s clunky. The md file will still have a useless -. If you want a page with longform and Logseq’s classic block structures, td is even more difficult to navigate since it hides all bullets (you can’t easily distinguish between paragraphs and other blocks). Images, LaTeX math, etc. are sometimes annoying to handle with nested blocks. Then there’s also compatibility with imported markdown files. Generally the freedom to write without bullets would be useful.
I really hope the devs will give longform some attention in the future, but I think there are still some questions to answer. If you remove the first-level bullet from a page, should that page be designated as “longform,” and no subsequent bullet structures would have block IDs? Or should all text between bullets be considered one block? Something else?
6 Likes
To chime in here … Logseq works great as a logical outliner. It wasn’t designed to function as a general-purpose notes app. The problem with kitchen-sink apps is that eventually you need to cut so many corners to accommodate every shelf in the kitchen that you end up with a product that does many things OK, almost nothing super well, and it kinda looks and feels like a kludge.
A great example of this phenomenon is actually Scrivener, mentioned earlier, because it tried to be a note-taker, document-writer, and book compiler in a single UI. And it’s … ok.
As someone who writes primarily long-form material, I question the value of long form optimized for Markdown. Markdown is great for documents intended for the Web. But if I’m doing something even a smidge more complex, I’m moving to LaTeX.
Radically rewriting Logseq to be “good for long-form writing” and then pretending that Markdown is wholly sufficient for that task probably doesn’t speak for the overwhelming majority of long-form-writer use cases out there.
3 Likes
Let me just highlight some text from the original feature request. I am doing this partially to respond to the last comment but also, and more importantly, to show how things have (or have not) progressed since I first wrote this post in November of 2021.
So the first question is whether there is any reason for Logseq to move in this direction, or if it should just perhaps make it easier to move your work into one of these longform writing apps? Maybe, but to answer that question it is helpful to first understand what the alternative would look like.
I then proceeded to break down the concept into four different features:
- Handle plain text files without any bullet points
- In-text citations, as well as footnotes/endnotes
- Document management that allows one to break up larger writing projects into smaller chunks (“sheets”) and to manipulate those chucks (split, merge, etc.).
- Output to standard formats such as PDF or ODT/DOCX.
Let’s look at these one by one and ask how they actually move away from how “Logseq was designed to function”?
Well, if we skip to #2, we see that Logseq already came with Zotero support built-in, and that many people who use Logseq as a “general-purpose notes app” would greatly benefit from improving this functionality - even if the goal is only to move your notes and writing to another app later on. (Especially if you want to move your notes to another app later on!) The team seems to agree and there is some kind of effort to do this, though it seems to be stalled right now. Note that the plan here is to have this as a plugin, so there is no need to radically rewrite Logseq for this.
There is also a good discussion about how to handle export to PDF and DOC here in the forms. One method is using an existing PDF export plugin with some custom CSS and Logseq’s built-in document mode, another is to use a separate script to filter Logseq Markdown for processing with PanDOC. There seem to be limitations with incorporating PanDOC directly into Logseq, but hopefully some of these tricks people are already using can be packaged into some form that will make them easier for people with less technical skills to use. I personally think working with Zettlr as an intermediary is a good option, but that also could be improved to make the process smoother.
Regarding number three, there are also some plugin developments that might help. I haven’t really explored these yet, but one is Full House Templates, and Sawhney is working on a folder plugin. Not sure if these, or something like these, could provide this kind of functionality (merging and splitting sheets), or if another plugin might be written to do this, or if it would actually involve some kind of core changes to logseq? It is a bit hard for me to say on this one.
Finally, that leaves number one. A number of people who don’t even care about longform writing have been asking for the ability to handle plain markdown files in logseq for other reasons. Document mode just isn’t enough. I still think this might be handled by a page-property flag. One could imagine this being something akin to how logseq handles PDF documents - as a separate kind of entity different from one’s outline. I don’t know. For this one I could see reasons why it might not be possible or desirable, but I haven’t really seen people who actually know how Logseq works make such an argument yet, so I remain hopeful.
In summary, it appears that some of the four features I requested can be handled by plugins (some of which are already in development), while others may require more work. However, the extent of the necessary work and its impact on Logseq’s core functionality is uncertain and should be fully considered. It is possible that creating a workflow to facilitate transferring notes to another app may be sufficient, or some minor adjustments could make this step less necessary. My intention in writing this post is to initiate a discussion on this matter, which I believe is crucial. I do not see any benefit in prematurely closing this conversation based on fears or assumptions that may turn out to be unwarranted.
4 Likes
If your post was a response to me, it’s not clear what, specifically, you’re responding to. And I am certainly not “prematurely closing this conversation.” I am simply raising a counter-point to your original post, which is in the spirit of both this forum and the advancement of Logseq as a platform.
If you’re looking for a combination of a linked-notes-outliner, task manager, and document editor, have you considered Emacs with Org-Roam?
I’m not going to repeat myself, but I will say this – Jurassic Park teaches us that Life Finds a Way. But technical debt also finds a way. Be careful of asking an app that was designed to do X to also do the Y it was originally architected to not-do. Even if the devs grant your wish, there will be consequences to the design and performance of Logseq that are unlikely to be trivial, given stuff as elemental as block-level addressing.
By all means, let the votes and discussion continue. But given the use case you drafted, I don’t think Logseq is the droid you seek.
1 Like
In my opinion, from the current logseq’s roadmap, it is difficult to support long text writing.
I just hope that developers can make the logseq’s export function more powerful, such as supporting Markdown with no marked point, and Tex files. This is enough for me to use LaTeX, Pandoc and other tools to compile, and then complete long articles.
With the current logseq’s export function, it has not been able to export PDF directly to facilitate users to print, which has caused me to hesitate to use logseq as my main note software.
3 Likes
I’d agree with you. There are many long form writing tools, some of which can import pre-existing markdown. I see Logseq as a superb research/ journaling/ meeting/ outlining tool which allows us to process, structure and articulate knowledge. Zotero integration to maintain references was a great addition for researchers to maintain sources without Logseq duplicating that functionality.
The most important thing is to be able to get information out (in my option), particularly without bullets. Cut and paste is often fine, as Microsoft Word or Ulysses (in my case) can handle formatting of a finished document.
If people want to develop functionality as plugins then that’s great, but I don’t think the Logseq team should be spending time on this. It risks Logseq being unclear as to what it is and scarce effort going into duplicating features of Scrivener and Ulysses which are already established players in a very niche market.
3 Likes
Hope you have felt our efforts on improving long page writing experience over past months.
We can do more on the long page UX & storage when the long page performance meets our expectation.
And, it’s always on our roadmap:
6 Likes
I have used Ulysses for 15 years, LS for almost 3. Together they meet my needs, but at a cost. There is significant friction for me in moving between the two in terms of time lost. I do it but it takes Markdown cleanup time and reformatting that I wish I didn’t have to do. If LS doesn’t move towards its own version of longform writing, I believe it is in the best of interests of LS to identify its longform “partner” and make the transition between the two as seamless as possible. To underline this point, if Ulysses were to come out with a direct backlink function (which my tea leaves suggest they are getting close to doing) and outlining capacity, Logseq would become immediately less valuable to me in its current state. I would likely leave it behind.
1 Like
That’s fair. I like Ulysses, but I settled on Typora as longform writing tool in the end.
You may have hit on something: Logseq don’t necessarily need to build functionality but rather a means of exporting in formats suitable for working in the major long form applications. That’s a much more straightforward proposition to implement than reproducing the functionality of a wide range of other products which have been being built for many years with substantial investment behind them.
Logseq may lose a little business to Ulysses, but there’s little point trying to be Scrivener or Ulysses when they already exist and their shared market isn’t huge. I expect Ulysses is eyeing up Scrivener’s business… It already has outlining (albeit quite different to Logseq’s).
1 Like
This is the last line of the original post:
“but even if only some of [these features] can be implemented it could help improve integration with existing longform writing apps that rely on plain text.”
1 Like
Perhaps that is what it said, but features in the original post like writing goals and document management (in core) go way beyond integration with/export to existing apps and reproduces some of their core functionality. A major part of the reason for using Ulysses is writing goals and managing documents within a project!
Even Obsidian, which in some ways could be better suited to longform writing, has no apparent plans to introduce functionality like that to its core.
If people want to write plugins, great!
I also wrote: “As such, it isn’t a standard feature request. Some of the ideas here might be spun off as feature requests on their own, but that isn’t the point. Rather, it is intended to start a discussion about what the best way might be for Logseq to achieve these overarching goals.”
Some features might be best as plugins, others might be best in the core, and others might be achieved simply by improving existing features such as reference management and copy-as functions. I’m not a programmer, so I don’t attempt to try to assume which features would make sense to accomplish in which way. That’s for others to decide, but I think it is useful for those who don’t use Ulysses or other such apps to understand the entire workflow.
1 Like
That would be a great développement of Logseq. I’m new in Logseq, and I choose it because it matches so much my way of working/thinking ! But I also need a “long form” tool. I am using SCRIVENER. But I am beginning to create all my PKM system in Logseq. Longform would definitely improve Logseq, by integrating all data’s of research, ideas, concepts, in the same app in which I write my long manuscript.
Using external app for writing, but needing the Wiki links like functions, the connections, the query’s tools, direct links with the research data’s created in another app (Logseq), during the writing process, seems to me that we loose all the benefits of Logseq, and my PK.
The different point of view, are very interesting. And maybe some plug-in would be the solution. If creating this feature lead to rewrite completely the logic of Logseq I understand that it’s not worth it. But some new functionalities, facilitating the longform, could be very useful. For complete features like Scrivener, Ulysses, it’s better using those specific apps. But for a big % of needs, e few plug-in/new features, would be perfect.
Thanks for this post, and sorry for my bad English. 
3 Likes
Friends, I’m a plugin developer and Logseq lover, I have developed many useful plugins like the TOC Generator that you can find in the Logseq’s plugin marketplace. I have just developed a plugin dedicated to longform writing and I’d like to invite you all to try it:
It’s a paid plugin but you can try it as many times as you want, it’s not on the marketplace and have to be installed manually, just follow the installation instructions on the project’s page given above. If you have more questions, feel free to join the dedicated Discord channel, it’s listed at the bottom of the project’s page.
3 Likes
I’ve created a new post listing all the various plugins that have been developed to help long form writing in Logseq.
2 Likes
Cross-referencing my comment about working on a plugin to display blocks like Gingko: