Safe save feature enhancement?

[arspr]

A suggestion born from real serious trouble because of my mistakes and Kobo being quite "weak". But it can be really useful against undesired critical mistakes.

What I suggest is adding an option to force an automatic Check Book, or actually the critical tests of it, when saving is launched. If any failure is detected, the user would be told and asked for confirmation about really continuing with the saving process.

It can save a lot of headaches if the users make serious mistakes while editing. Of course you can always perform a manual check every time you are going to save... but at least me, I'm not so careful or I am fully sure I have made just small, little , irrelevant changes...

My real problem has been (I think) that a missing </p> plus "kepubization" of the epub through jgoguen's plugin has created a kepub.epub which has corrupted the internal database of my Aura HD twice, (yes, incredible but real), forcing me to make a device reset each time. A process, I can assure you, which is a whole PITA.

Even without this secondary crazy effect, I would have been really grateful about not having lost the original error-free version of my epub. So, is it a feasible enhancement?

[kovidgoyal]

I dont see why you would want to check on every save. That's got to be pretty disruptive. What you want is to check on close not save. So that when you are done editing the check is run automatically.

[arspr]

It's just a matter of how one works...

I know that I can:

• Perform manual checks every time I save.
• Wait till I'm finished to save (with his manual check or your proposed automated one on exit + save). (But I'm always fearing there's going to be a power shutdown, a windows crash, whatever...)
• Thousand of other options.

But I really would prefer an absolutely safeguard measure like perform critical checks, (I insist on "critical"; I mean parsing errors, I don't care about the book containing the Calibre bookmark file) on every save, even if it makes that saving process somehow slower (even with a waiting clock displayed in the middle of the screen). And remember that I would like to be asked for confirmation about continue saving or not if critical errors are present, in a similar way you are asked when quitting without having saved.

I'm in an ageing Core-2-Quad 2.4GHz and running full Check Book takes about 3 seconds at most in "Infinite Jest" (which is a really long book). I don't really mind waiting 3 seconds but being fully sure that the lose of "undoing" function associated to the saving process is not important.

But as you say, that possible waiting can be REALLY annoying for other users. Because of that, I ask (if possible) for a option about it, not an always-enabled feature...

(I would likely code it myself if capable, but that's not possible, I fear... )

[kovidgoyal]

"critical" is not a well defined concept. For you a parsing error might be critical because of your use of kepub, for someone else it might not be critical.

If you have a power shutdown or windows crash, while you are editing a book, presumably you will restart your computer and continue editing the book, in which case the check will run automatically the next time you close the book.

There is no loss of undo associated with a save. You can undo or use checkpoints after a save.

[arspr]

Originally Posted by kovidgoyal

"critical" is not a well defined concept. For you a parsing error might be critical because of your use of kepub, for someone else it might not be critical.

Of course, but in fact, you have actually catergorized the errors/warnings. By critical I mean the actually "red crossed" ones. IIRC, we actually have errors (red ones, these ones are what I'm calling "critical"), warnings (yellow triangles) and informations (blue circles).

Originally Posted by kovidgoyal

If you have a power shutdown or windows crash, while you are editing a book, presumably you will restart your computer and continue editing the book, in which case the check will run automatically the next time you close the book.

As I wanted to imply it's just a matter of personal workflow (with all its personal little bad-habits involved). I would really like this feature because of the way I work. As example imagine that you close the editing session with only after a WIP tweak session because you don't have more time, because it's late, you have to go to work, or whatever. In this case a just check-on-close would be sub-optimal for me, because it would inform me about troubles when I don't have time to fix them any more...

But nevertheless, I'll try to adjust my workflow to the capabilities of the software.

Originally Posted by kovidgoyal

There is no loss of undo associated with a save. You can undo or use checkpoints after a save.

Incredible, I'm too used to MS Word, I fear... I hadn't noticed that little extremely GREAT feature.




And now a side comment. I've reproduced a </p> erasing as a test. And the error warning Check Book gives is shown in the attached screenshot.

As you can see the important part of it is in fact line 16 which is where the error is actually located. But in the user-friendly description, line 16 is not mentioned at all (but line 24, the ending </body>, is). I think mentioning line 16 rather than (or in addition to) line 24 would be a good user-friendly tweak. More over giving two links to either line 16 or line 24 would be great.

[kovidgoyal]

As I explained the last time you brought up line numbers for parsing errors, while it might be clear to you that a closing </p> is missing it is by no means clear to anyone else.

Consider this:

<b>one word
<i>two</i>

There is a </b> tag missing, all of the following are perfectly possible correct closures:

<b>one</b>

<b>one word</b>

<b>one word
<i>two</i></b>

Therefore the checker can only report the location where the unclosed tag starts and the last legal location for the tag to be closed, which in your case was before the </body> tag.

[arspr]

Yes I remember that explanation from you: parser can only inform that this beginning tag in this line doesn't match with this ending tag there in that other line (or even in the same one). It cannot "know" what actually causes the mismatch.

And that info is what we have in the left "technical" part of the check report. But in the right user-friendly description we only have the ending part of the equation.

What I'm suggesting as an improvement is also giving them both in that right user-friendly part.

[kovidgoyal]

That isn't possible since the parsing library does not expose that information in a machine readable manner. In theory one could write e regex to try to extract that info from the error message, but it is not very stable, since the error message could be translated.

[mrmikel]

Just a wild hair--if such an error were found, can the parsing library be run backward from the end of the document with closes looking for opens instead? At least it might get you closer.

[kovidgoyal]

No not really. XML parsing cannot be done in reverse.