[eschwartz]

Originally Posted by BetterRed

Please name the plugin and version, I'd like to see what happens if I remove it! I thought the following had been part of the furniture since at least 2008 :-

Attachment 144404

As a linux user, I haven't touched Notepad++ in quite some time (and only rarely then).

But I did a Google Search: "notepad++ autosave" and got a solid wall of links to the same plugin by Franco Stellari and not one mention about a builtin feature.

Typical - I don't want it, ergo no-one should want it!

It takes some of us days to pare down a few pages of purple prose into a succinct sentence or two. Sometimes we like to get back to where we were this morning at about 10am - or where we were first thing yesterday morning.

At the cost of filling up your hard drive with snapshots. Each copy of which, differs by a letter or two.

It seems, to me, to be a solution in search of a problem.

Now, I get virtually unlimited undo-redo in vim by virtue of activating ":set undofile" and that change history is step-by-step AND discreetly (and compactly) stored in one single undofile per edited file. Which by preference is stored in ~/.cache/vim/ where it won't bother me and can be easily purged if necessary.
And in the same place, a swap file with the saved state of the edited file, which is left behind if vim crashes or is killed, and can restore the file.

IMHO that approach is fundamentally superior to something that sounds more like an overanxious poor man's version control system, with no methodology beyond "dump piles of data on you and let you sort through them".
And certainly superior to "set it and forget it and have all your files overwritten without warning".

If the entire package is saved periodically and one or more components is in a state of 'unreadiness' - ie open tags, invalid links, out of synch manifest etc, such that the resultant so-called 'EPUB' would not pass muster with epubcheck, flightcrew or any other epub validation tool, then should it be saved as an EPUB.

Then that is the full document they painstakingly created, and presumably, that is what they want.
I think you are making this more difficult than it has to be.

What happens if the user locates the 'so-called EPUB' as of 10am this morning and asks Sigil to open it - will it, despite all those structural errors and if not, what then. I have no idea - but I wouldn't put any money on it - you're free do so if you so choose.

Yes, it will open it, the same way it was able to hold the internal state during editing.
I am fairly positive that it is impossible to save an EPUB with Sigil that cannot then be opened by Sigil -- but if it did then that would be a fairly significant bug and would be fixed, not hand-waved away as a feature.

If only the components that have changed since the last save are saved, then comes the problem of reassembling a valid EPUB as of 10 o'clock this morning.

I still don't understand what "only the components that have changed since the last save" is supposed to mean.
In order for Sigil to save the EPUB, it must recreate the ZIP with the contents of the changed "components" (read: files?) in addition to the unchanged files.
Also known as... the current state of all files!

Are you trying to suggest something to do with "recreating" vs. "updating" the ZIP?

Let me make it clear - I am NOT advocating Sigil should have an auto-save feature, far from it. But not on the grounds that I don't want it therefore nor should anyone else - I'm not so arrogant as to think I matter that much.

Well, good for you that you support other peoples' right to want auto-save.
I don't believe I am being arrogant when I express my personal opinion on the usefulness.

All it is, is an opinion. Anyone else is free to air their opinion as well.

I am advocating it not be done because I suspect its not easily done, otherwise it would most likely already be done, in Sigil, and similar software. The fact that its not, suggests to me its not as easy as all that.

Yes, that is another reason to think it won't happen.