I’ve imported 2000+ notes from Obsidian. Logseq took around 30 minutes to parse them. I’ve then started to check them randomly, to see if I found anything wrong.
A lot of pages appear to be empty, even though their files are not. When this happens, the options to show the file in the directory and to open them in the default app, are unavailable.
If I write something in them (inside Logseq), I get a warning about different content on disk, and I have the option to restore it.
UPDATE: This is no use, because whenever I Refresh the graph the pages are erased again.
What I’ve tried
Restarting, re-indexing and refreshing.
I haven’t figured out a pattern for this. Initially, I thought that it happened to notes with diacritics in the title, but that doesn’t seem to be a sufficient condition.
- macOS 11.6
- Logseq Desktop v. 0.4.4
I’ve listed all the filenames with diacritics (500+) and I’m going through their respective Logseq pages. The vast majority of them seem to suffer from the same problem.
On the upside, I think I’ve pinned down part of the problem:
When I search Logseq for the title, I get two (seemingly) identical entries. One is empty and the other has the original content. The root of the problem seems to be two different Unicode endpoints for the accented characters.
For example, one
U+00ED (í Latin Small Letter I with Acute) and the other is the unaccented
i combined with the accent in a character sequence.
I kind of hope that it’s something on Logseq’s side, as I have no idea of how to fix it.
I’ve been experimenting with Python’s
unicodedata module, namely its
normalize function. I’ve ran all the files through a script that “NFC”-normalizes both filename and contents, and then started a new graph from scratch. The problem persisted.
Then, I noticed that the diacritics in the file names were still decomposed. Apparently, macOS decomposes them automatically, so it seems that there’s nothing I can do on that front.
Maybe normalising everything inside Logseq would solve it. Does this make any sense?