But yes, Shift+Tab should work as well. But no need for a prompt because again Enter, Shift-Tab and starting an outline with - are standard operations in many, many document and note-taking apps.
I mentioned the Yes/No dialog because switching between blocks and normal paragraphs could be a destructive actionā¦ I donāt know how Logseq assigns IDs to blocks, but what happen if you accidentally turn a block into a paragraph and the ID is lost? This is just an example to explain what I mean.
Ah yes, good point. But it doesnāt have to be destructiveāthe ID could be preserved.
In this case of IDs for arbitrary Markdown blocks, Iām only aware of Obsidian having coming up with a design for block references (Link to blocks - Obsidian Help) and it could be re-used to a certain extent, thus encouraging a de-facto standard. (Anyone aware of any other Markdown apps that have block references for arbitrary parts of Markdown?)
So perhaps, doing something similar and writing out the block ID at the end of a block as ^62d61185-6094-4c39-9196-ba630963d03e (which logseq would hide in the UI, just as it does with IDs for list items) would be close enough to Obsidianās style for Obsidian to immediately support it on some aspects of its UI: rendering in light-gray superscript (āhalf-hiddenā) and references to it would work out of the box.
Obsidian has a somewhat different model of [[page#^local-uid]] rather than ((global-uid)), so Obsidian references created today would work and look like [[A Page#^62d61185-6094-4c39-9196-ba630963d03e]] which is a bit less user friendly but would still work.
And because this solution is sufficiently close to Obsidianās, it could encourage the Obsidian core devs to tweak their implementation to further support the concept of globally-unique IDs. For example, to make autocompletion more user-friendly, Obsidian could do a little bit of work to recognize these global UIDs and avoid making the user first complete on the page name.)
Since Logseq does support long form writing mode (Document mode), then Iām wondering if itās just a matter of creating a plugin that effectively switches between the modes.
A single page can be have both long form writing (no bullet points or paragraphs/blocks preceded by a ā-ā) and paragraphs with Enter or CR at the end.
A plug-in would switch between the twoā¦however is this any better than the Esc+td?
One thing that should be an option is that when LS is in Document mode, each paragraph has an indent. Iād prefer not to have indents.
Another item I noticed that is problematic with Document mode is how to do headings. In the bullet mode, you can use the hashes to indicate level of heading, but that doesnāt seem to work in Document mode. Other font formating does seem to work (highlight, italic, bold).
1 Like
I imagine a plugin canāt change the underlying Markdown format that is used. Take a look: in your filesystem, go to the pages/ directory of your Logseq graph, and open a markdown file with a text editor and see how Logseq writes markdown (and stores block IDs).
So this would have to be changed in core.
2 Likes
But why if you use Obsidian with LongForm , really is possible, writing in logseq and save in the same obsidian folder?
I donāt see how this ālongform writingā would be useful.
What is useful for me is supporting all Markdown files, not only the ones with indented lists, because this way you have more interoperability with other applications and tools, including Pandoc to export documents.
But longform writing alone? In Logseq you can already hide the bullets with t d (Document Mode). So why one would want anything beside support of all Markdown files?
Whatās wrong with pressing t d and write paragraphs as blocks without indenting them? The UX is exactly the same of any other editor like Obsidian.
For me, this thread should be renamed āSupport every Markdown fileā and how to present normal paragraphs in the UI should be discussed.
The UI doesnāt need to be much complex, basically all the Markdown editors support paragraphs and lists. Logseq support only lists.
Logseq could just start a new page with a - bullet and pressing Enter creates new blocks that can be indented. But the news would be that you can delete the bullet of a first-level block and Logseq would save that as a paragraph in Markdown, not as a list. Enter in a paragraph would create another paragraph.
How to delete the/insert a new bullet? There are two options:
- Press
Deletewith the cursor at the beginning of a block / press-at the beginning of a paragraph to turn it into a block (basically what other Mardown editors do) - Press
Shift+Tabto turn a first-level block into a paragraph / pressTabto turn a paragraph into a first-level block (basically treating paragraphs as another level of indentation above the usual ones)
9 Likes
This is a feature request for longform writing support, if that isnāt what you want, you should start a separate feature request.
3 Likes
Iām trying to help, something you didnāt at all with your attitude along the thread.
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