[Bug] Text and undo history lost while typing
Completed
Since upgrading to beta 48 earlier today, I've experienced weird behavior when writing. While I write, suddenly some letters/words are dropped. The cursor moves back as if I never typed them, and the undo history is lost. (Cmd-Z does nothing.) Of course this makes nvUltra unusable for me.
This happens at the same time a file named ".dat.nosync[NNN]" flashes in the file list, over the one I'm editing. I found another thread mentioning these files, even though that bug concerned behaviour when creating new files. I guess maybe this other file somehow gets focus, swallowing my typed characters, and the original file is then loaded again, without undo history.
(I sync my notes through "Box Sync", though it happens even if I turn syncing off.)
-
I'll try to test with Box, though the `.dat.nosync` files should be separate from specific sync services, if I understood/remember correctly.
But even then, when the index is updated in the background, it still should not change which file is actively loaded.
Does it happen if you work in a folder outside of your Box folder?
Any relevant messages in the Console application when this happens?
0 -
Daniel Sandbecker -- is this still happening in build 49?
0 -
Hi Fletcher,
Yes, I would say that it is still happening in build 49, but not always and sometimes with a slightly different behavior.
When writing in my original notes folder (the one synced with Box) I've experienced it once or twice, but it's hard to reproduce. The dat-file still appears for a moment now and then, but it doesn't "steel focus" every time like before.
But I also created a new notes folder under a path where no sync service should be in effect, and there it happens all the time, but now with a file named "(error)" appearing in the file list instead of the .dat-file.
(As I haven't been able to intentionally reproduce the issue in the original folder, I'm not really sure if the flashing file there was a dat-file or an "(error)"-file those few times it happened.)
0 -
Just after writing I've experienced it multiple times in the original Box folder, and the flashing file was certainly .dat.nosync*.
It still doesn't happen each time such a file appears though. But once it's happened, it continues while writing in the same file.
0 -
Can you send me a zipped copy of the new folder where it occurs all the time?
0 -
Sure, but it's just an almost empty directory. I created it as ~/tmp/notes/Notes and have now zipped the "notes" directory and everything below.
Where do I send it?
0 -
Yeah -- but something screwy is happening for you that isn't happening for others. It's either something "strange" with your files, with your computer, or with you. ;) I like to assume it's the files first (e.g. something idiosyncratic in the way the files are used compared to most common use cases), and then the computer (OS, hardware, networking, something outside of the app itself). Only after those are thoroughly cleared should we consider "user error" as a likely cause.
If small, can email to admin at multimarkdown dot com
If bigger, can open a support ticket here and attach, or use a dropbox link or something similar.
Thanks!!!
(P.S.>> If I can't immediately replicate it, the next that is helpful is a screen recording showing exactly what is happening (e.g. with Quicktime Player) -- sometimes there is a unique combination of settings or layout or something that I can pick up on by watching what happens in real time.)
0 -
Also -- what is the full path of the new folder that you are using?
0 -
Thanks, I've sent the zip-file to the address above. The full path to the directory where I get the "(error)"-behaviour all the time is: "/Users/dan/tmp/notes/Notes".
But I tested some more, based on your fail check process described above, and got some clues that it might be "something outside of the app".
It turned out that this is probably Panda Antivirus (mandatory at work) doing something weird. If I turn the real time AV scanning of, both the error-files and the .dat-files stop appearing. So I guess it's Panda AV that creates these files, but I still don't know why this causes the current file in nvUltra to seemingly reload.
At first I thought it might be because I have "Automatically update when file is changed by another program" checked in nvUltra. And when I first turned this setting off (while keeping Real time scanning on), the error seemed to have disappeared. I assumed that Panda AV copies a temporary (and slightly stale) file over the currently edited file, and nvUltra reloaded with this new file. But now when I toggle this setting on and off it happens anyway, so I'm no longer sure. I've tried setting "Automatically update ..." to off, restarted nvUltra, and the "reloading" still happens.
0 -
Interesting. I don't have Panda Antivirus, but maybe I can try to explore some ideas based on that.
0 -
1. When I test editing one file on two computers (via iCloud), things work fine. I can make changes on either machine, and they appear appropriately on the other. If I make simultaneous changes, I get notified about the collision and am asked to make a choice.
2. Same thing when I edit in nvUltra and MultiMarkdown Composer at the same time on the same computer. Or nvUltra/Composer/TextEdit (keeping in mind that TextEdit doesn't merge like my apps do).
3. When I turn off "Automatically update...", I get an alert ("File has changed") that asks me to choose how to resolve the issue. So if Panda were re-saving an old copy, that alert should still fire.
It is possible that Panda AV is doing something else:
1. Rewriting the file without using proper macOS file handling. macOS offers APIs to allow reading/writing files in such a way as to avoid simultaneous writes/deadlock issues. If this is not implemented correctly, strange things can happen. This doesn't *feel* like that problem, but I suppose it's possible.
2. Panda AV could be locking the file somehow. I suppose it could cause something screwy to happen if nvUltra saved a file, but was prevented from completing the save?? But even then, it queues up saves, processes them in order, and tries to keep the queue limited to 1 pending save, and a final save if things change while waiting.
One thing to experiment with is the "Undo Coalescing" preferences in the Advanced tab. nvUltra saves the file at the same frequency that it coalesces undo steps. (e.g. typing one letter at a time can result in an undo queue of one letter at a time, one word at a time, one sentence at a time, or one paragraph at a time.) If you set this to "Don't coalesce" and open the file simultaneously in TextEdit, you'll see each character update one at a time if you type slowly. If you change this, you'll see the frequency of updates to the file (and therefore the TextEdit document) change. Maybe slowing this down will improve things??
A few quick google searches don't turn up anything useful for me in terms of what Panda AV is doing behind the scenes.
I have added some new logging features to the next build (50) that might help shed some light. Once that is available, try this in the terminal, and then run nvUltra with the Console application open:
`defaults write com.multimarkdown.nvultra STDebugLevel 10`
This will generate a *lot* of information, so you only need to test for a little bit. Use a file without any confidential information, because some of the file contents are included in the debugging information. Filter the display for `nvultra` in the searchbar in the upper right and send the contents to me via email and I'll dig through them.
Make sure to set the debug level back to 0 when you're done. ;)
0 -
This is happening to me as well. In beta 50.
I set the defaults write com.multimarkdown.nvultra STDebugLevel 10 command in terminal, and typed a test file that demonstrated the behavior, but I don't understand "Filter the display for `nvultra` in the searchbar in the upper right and send the contents to me via email and I'll dig through them." I don't know the location of the display. Sorry. Bear of little brain.
I can also run in recovery mode and see if it is some plugin etc, causing it.
0 -
You have to run the Console application -- that's where macOS logging information can be most readily accessed.
0 -
Jeffrey Long -- are you using Panda AV (or something similar) as well?
0 -
Also -- I have just wrapped up a major project at my day job, and am hoping to dive into the few outstanding known issues with nvUltra tomorrow. Any further information you come up with for this would be great! Thanks!!
0 -
Unfortunately (timing-wise) I’m on vacation all week and don’t have access to my Macbook. I’ll get back to you as soon as I’m back.
/Daniel
0 -
Daniel Sandbecker -- No worries, enjoy your vacation!!
0 -
Another tact, since I have yet to find an answer -- if you're experiencing this, can you send the output from `defaults read com.multimarkdown.nvultra` to us as a support ticket. The only personnel information that is really in there is path information about folders and files that you have used. If that concerns you, you can delete those lines before sending.
Maybe this will point towards a way to replicate the problem...
Thanks!
0
Please sign in to leave a comment.
Comments
18 comments