search

olivierkes / manuskript

A open-source tool for writers
http://www.theologeek.ch/manuskript
GNU General Public License v3.0
1.7k stars 226 forks source link

Navigating in the text editor tab is super slow + suggestion: confirmation message for overwriting a file #1286

Open Felina-Lain opened 4 months ago

Felina-Lain commented 4 months ago

I just had this issue, using Version 0.16.1-5a10925 which led me to loose hour of work. Context:

I got manuskript recently, found it easy to use and quite practical, but ran into an issue very quickly: navigating between chapters in the text editor is extremely slow. And I don't mean 5 secondes delay, I mean up to 30 secondes to open a 3000 words chapter.

Which then led me to my lost work and my suggestion (because I'm pretty sure it's too late to recover my chapter) I was trying to create a copy of one of my chapters, to have two version to try different things in both in parallel. I copied the chapter without issue (right clicking it and choosing copy). Then I tried pasting it into the folder I'd created for it. The navigation lagged behind so hard, so that when the subfolder opened, instead I clicked paste while my mouse was over another of my chapters. There was 0 confirmation message or warning, and I didn't realise the horror right away. When I did I tried to recover the work, but there was no deleted file, or anything. And the revision option was off because the settings said it could create bugs and crashes so I hadn't dared turning it on.

So one: I'd like to understand why it's running so slow. The software itself is on my ssd. It shouldn't be that slow, I think?

Second, I'd very much like to suggest a confirmation popup whenever you try to overwrite a file with another in the menu. Like "Are you sure you want to overwrite [file A] with [file B]?"

If I need to add some log files, for the "super slow" problem, I'll do it.

TheShadowOfHassen commented 4 months ago

Manuskript, unfortunately, at the moment is very laggy for larger files. The way to fix it is to completely rewrite the system, which is being done. Unfortunately, this project is mostly worked on by one developer @TheJackiMonster, and he is busy with other projects.

I am really sorry that you lost your story. I've had it happen too, it stinks. The best way to prevent project fatalities is to back up your story, I'd do it at least once every day. This problem would also be fixed in the new gtk rewrite.

TheJackiMonster commented 4 months ago

The performance currently is bottle-necked by the CPU in most cases, not the drive. That's because every change of a file (chapter, scene, ...) will cause processing in terms of conversion for visual representation as well as potential spell & grammar correction, word counting and some other features automatically.

The idea to fix that is already there and partially implemented. But that's as part of a whole GUI rewrite which takes a lot of time and resources. But the basic concept is that we process each file asynchronously so that no lag is caused for the end-user (only a short period of loading in worst case).

For now I can only recommend creating backups frequently.

Felina-Lain commented 4 months ago

Manuskript, unfortunately, at the moment is very laggy for larger files. The way to fix it is to completely rewrite the system, which is being done. Unfortunately, this project is mostly worked on by one developer @TheJackiMonster, and he is busy with other projects.

I am really sorry that you lost your story. I've had it happen too, it stinks. The best way to prevent project fatalities is to back up your story, I'd do it at least once every day. This problem would also be fixed in the new gtk rewrite.

The performance currently is bottle-necked by the CPU in most cases, not the drive. That's because every change of a file (chapter, scene, ...) will cause processing in terms of conversion for visual representation as well as potential spell & grammar correction, word counting and some other features automatically.

The idea to fix that is already there and partially implemented. But that's as part of a whole GUI rewrite which takes a lot of time and resources. But the basic concept is that we process each file asynchronously so that no lag is caused for the end-user (only a short period of loading in worst case).

For now I can only recommend creating backups frequently.

Fair enough, thank you both for the answers, pretty much what I thought as well. I knew going in that manuskript was still in dev, so I did expect bug, but obviously wasn't cautious enough. That's me burned once ^^" Thanks for all the work on it though, the software really got potential!