Fsnotes: Note is rendering with lines in the wrong location

[bnham]

Describe the bug
While editing my note, especially when using automatically bulleted lists, the view of the note becomes corrupted and random lines and characters are inserted in the wrong place. Note that the backing storage of the note appears to be fine on disk. It's just the view of the note in the UI that's incorrect.

For instance, see the attached screenshot. On the left is the note on disk as seen by TextEdit. The last line says "Client initiates DH key exchange" in the actual text file. However, in FSNotes on the right, you can see that the view actually shows "Client initiates DH key - Attach" as if the string has been inserted into the buffer in the wrong place.

I've also attached the note I was editing. Try editing it and adding some new bullet points to the note. Eventually the editing view starts mangling the text as I've described above: high-perf-browser-networking.txt.

I am seeing this in FSNotes 3.6.2 (293).

To Reproduce
Steps to reproduce the behavior:

1. Edit the attached long note. Try adding bullet points, code blocks, and other elements that trigger the text view to do complicated insertions
2. Eventually the text view becomes out of sync with the actual text file on disk and it looks like strings are inserted into incorrect locations in the text view.

Expected behavior
The text view should accurately reflect the text file on disk.

Actual behavior
The text view goes out of sync with the text file on disk and some of the text in the view is mangled.

Workaround
Haven't found any workarounds yet.

Supporting Files
See summary for a screenshot and example long text file.

Desktop (please complete the following information):

• OS: macOS
• OS version: 10.14.6 (18G87)
• FSNotes version: 3.6.2 (293)

[glushchenko]

Thanks, i will try to reproduce

_{Sent with GitHawk}

[glushchenko]

Anyone can reproduce this?

[alex-kovac]

I was not able to reproduce the reported issue.

[gingerbeardman]

Cannot reproduce. Tried editing.

Can we get a smaller reproducible document or specific series of steps @bnham ?

[bnham]

I'll try--I've noticed this in several different notes over the past few weeks, but there doesn't seem to be any particular rhyme or reason to when it occurs, other than that it seems to have something to do with all the automatic formatting that happens in the buffer e.g. when you make lists or add code blocks.

If there are some methods in particular that are useful to log for insertion into the text view, I can also try building the app and adding some log lines to see if I can figure out what's going on.

[bnham]

I actually just upgraded to the App Store version 3.7.0 (303) and I can't even edit the note anymore. When typing in the buffer, nothing shows up and the app dies in CFRunLoop's top level exception handler with his exception: -[NSLayoutManager _fillLayoutHoleForCharacterRange:desiredNumberOfLines:isSoft:] *** attempted layout while textStorage is editing. It is not valid to cause the layoutManager to do layout while the textStorage is editing (ie the textStorage has been sent a beginEditing message without a matching endEditing.)

Full paste of the crash: https://gist.github.com/bnham/41db331f7ca8f022d2d9981940b85924

I then did a build and install a debug version of top of tree from commit 0e34de6 and was not able to repro the issue in the debug app. Bummer.

[glushchenko]

Please provide file that crash FSNotes

[bnham]

It's basically the same file as before, with a bit more text (note that on my computer the file has a .md extension not .txt but GitHub only allows me to upload .txt):

High Performance Browser Networking.txt

Like I said though, I cannot repro the crash from the debug build in XCode.

[bnham]

So having a look at the code, the logic around Note.markdownCache seems a bit suspicious, since it seems like that method can be called on the same note from multiple threads at the same time. (The self.caching guard there isn't sufficient to prevent multiple threads from executing the method at the same time due to possible memory reordering between threads.) This can result in the same NSAttributedString instance backing the note being mutated on multiple threads at the same time. But since I can only repro this on the prod version and I don't have symbols for the prod version, it's hard to prove this one way or the other.

One workaround I've found is to disable Markdown editing completely, e.g. by renaming the .md that I'm editing to .txt and to disable the txt-as-markdown preference so that all the fancy formatting is off. That allows me to edit the note again.

[glushchenko]

I reproduced this, and no, problem not in markdownCache. Tried to disable markdownCache, but app still crashed

_{Sent with GitHawk}

[glushchenko]

@bnham please try FSNotes 3.7.1 https://github.com/glushchenko/fsnotes/releases/tag/3.7.1

[bnham]

The crash and inability to edit the doc no longer occurs in 3.7.1 for me. I am actually still sometimes seeing random line breaks being inserted into the buffer when using bulleted lists but it seems better than before. Maybe I should close this and reopen when I find a better repro case for that?

[glushchenko]

Yes, please provide steps for reproduce and i fix that. Thank you for feedback 👍🏻

_{Sent with GitHawk}