I just downloaded a rather large markdown file into my pages database and it has created a new page. each block is a lot of text and I’m getting this message: Large block will not be editable or searchable to not slow down the app, please use another editor to edit this block.
I am seeing the same red banner (“Large block will not be editable or searchable to not slow down the app, please use another editor to edit this block.”) but my block is only 37 lines and I am still able to edit it.
I’m not sure this is a bug. I’m very happy Logseq introduced this as large code blocks were what was slowing down searching so much that I had to quit the app and try again. Maybe this is because of me abusing code blocks to dump large JSON or JS files when I was migrating all the stuff I had dumped in random sticky notes into Logseq, though.
Maybe there should be a config setting to toggle whether you can edit and/or search large code blocks and/or a config setting to adjust the limit max. code block size. Had a look at the code and found the relevant PR that introduced the feature (#6455). There’s a
:block/content-max-length option now.
I just want to know what to do about this. What md file should I edit with an external editor, and how should I chop it up so Logseq can put both chopped up blocks one after another on my journal page for that day?
I think it’s just better to not bring in big files or if it’s absolutely necessary, bring it pre-chopped. Only editing is not allowed but you’ll still be able to reference and embed those blocks.
I understand the advantages of limiting search for large blocks, but we should be able to edit the block, or to change the limit.
Let me explain to you one of my workflows:
- I use a e-reader and I highlight the text.
- From a txt file, I copy paste to Logseq.
- In Logseq, I “distill” the text (second brain / smart note like)
Before the “length max” feature:
- Up to 150,000 characters in one copy/paste in one block.
- If the navigation slows down, I split the block in several blocks: it never took more than a minute.
- Then I “distill” my notes.
(If Logseq is slow, I knew I should diminish the block’s size.)
Now my workflow with the limitation
- First, buy/own software to count the character, and edit the text, as Windows Notepad doesn’t do that (Logseq neither). I tried without a counter of characters and became mad how low is the new limit and how many times I had to cancel and retry…
- select some text, cut/paste, over 30 times for my 150,000 characters example (my highlights = 12% of the book)
Read large books and using Logseq for notes is a lot harder now.
If you have any “frictionless” solution for my workflow, I would appreciate it.
obsidian is still better here. It has word count in built. I also uses ereader highlights here in logseq but now getting error… anyways i am going back to obsidian!
Hi, first I didn’t get how to use the tips from @cherryblossom.
I was looking everywhere for the option he wrote about
When in fact you just need to add it with a value.
thanks for this fix. I changed my setting from 10000 (default) to 25000 to enable more long-form writing.
Plus one on this: I’m bringing in existing .md files and just can’t figure out what I need to do to break the ‘one large block’ (if I’m understanding correctly?) into multiple ones.
Or is the problem the size of the .md file? Its a bunch of saved kindle highlights from a book, and not many actually: 1.7k words, 12k characters.
I tried adding a * ahead of each quote, thinking this might break the page up into a block per quote, but no dice.
Actually, I figured out what I had to do:
start each block with - rather than a *
Seems I need to do some more reading about what defines a block, and logseq’s flavour of markdown still