Doesn't save changes

[theducks]

I sometimes do it the same way.
OCR cr*p

I am doing a spell check and SEE a nearby error eg. Br oken word.
I fix it (I do remember to do a refresh, but not immediately).

Sometimes 'in document fixes' are also faster because the search-replace find next word, does not need to happen.
If I don't refresh, the find phase just fails (no biggie)


Just to clarify what I am seeing: Intermittent. , I do frequent saves.

I fixed that 'Broken' and later refresh the list.
Bro is back on the list (and Bro ken is back in the document)

[Tex2002ans]

Originally Posted by mrmikel

My sympathies on checking a 4400 page document.

Well, it is 12 years of a quarterly journal. ~48 quarterly journals, ~100 pages each. I just jammed them all together and decided to tackle them as one big chunk (much easier to catch typos/common errors across a set of them, and easier to make it look consistent. The same applies to Volumes of a work too, I typically tackle all sets in a Volume at the same time.)

Originally Posted by mrmikel

I hope you added the correct ones to your dictionary, though it might be easy to wait until done and add the residue to the dictionary all at once. However, easy in this context is a relative term!

Heh, I will figure out all the fixed hyphens later, and add them to some sort of list. Toxaris's ePUB Tools has a whole Search/Replace tool which seems like it would be QUITE good for stuff like this.

I will be running that tool through some thorough testing too. (Already pointed out a few minor fixes which Toxaris implemented).

Originally Posted by theducks

I sometimes do it the same way.
OCR cr*p

I am doing a spell check and SEE a nearby error eg. Br oken word.
I fix it (I do remember to do a refresh, but not immediately).

Yep, this is exactly how I do it too. I can say I NEVER touch the "change selected word to" button, and do all of the fixes manually, while quickly scanning the surrounding area for any other errors I might stumble across.

[theducks]

Originally Posted by Tex2002ans

Yep, this is exactly how I do it too. I can say I NEVER touch the "change selected word to" button, and do all of the fixes manually, while quickly scanning the surrounding area for any other errors I might stumble across.

I may do a simple keyboard correction or I may use the (red underlined: pulldown suggestion. Single use only. none of the other context menu items)
This is issue really weird. I can't figure how it would revert WAY later in the session (I have switched tabs, done some work, switched back and it was still )

[AnotherCat]

[QUOTE=Tex2002ans;2868388]...Doing it the manual way, there is no way to "ignore" a word that you already know is correctly hyphenated.
If "long-term" shows up 183 times, you had to Next 183 times.
If "short-term" shows up 111 times, you had to Next 111 times.
If "Irvington-on-Hudson" shows up 34 times, you had to Next 68 times.
Now, since all unique words are shoved into the list ONCE, this really saves the amount of time your eyeballs have to work + how many times you have to ignore/fix mistakes.
Just those three words, you have wittled down 362 clicks into a quick look at a list.[QUOTE]

You appear to have done the injustice of assuming that what I stated applied to everything. In fact my original response was to the specific case of very poor OCR as was raised by another poster. I then went on to give the impression, correctly, that approach was in fact my common one. But you have extrapolated that into my including complex and 4,400 page books as well, whereas I was talking in general terms. I also did so in this Calibre Editor forum and so ignored raising what one may do outside of Editor, and was assuming the typical simpler use that most users put it to. I expected one of greater talents to see that was so and to give some space when interpreting.

In your quote above you give some (meant to be typical? I don't know) statistics. In fact for a typical fiction book, for example, one may be lucky to find 10 hyphenated words per chapter, or 10 cases of a particular hyphenated word in the whole book. Nor will there be a fleet of the likes of 183 "long-terms", 111 "short-terms" etc.; one will be unlucky to have even one of such frequency (I've been looking in a few fiction books to check).

There will likely be many more hyphens than that but those being such as interruptions to character's speech (e.g. "I said that we are going to-"), used instead of ems, etc., and which are most easily eradicated, if need be, by means other than spell-check, and if of the interruption "to-" case each unlikely to of frequency worthy of doing a bulk ignore on them. So for the case of working with clean text in ordinary work, the statistics you give are, in my view, exaggerated. But, as always there will be exceptions, in which case give the space to recognise that I may take an alternative approach to those.

Some examples using your hyphenated words to show dangers of bulk assumptions-

You give the example of "long-term" as being a unique word for bulk ignore; it is indeed a unique word when used correctly in the text as an adjective, but likely not be if used otherwise. For example, should the use along the lines of "he was incarcerated for a long-term" be accepted? Bulk ignore results in that potential error remaining uncorrected. Exactly the same risk applies to your other example of "short-term" (e.g. is "he was incarcerated for only a short-term" correct?) and the many other similar examples one comes across.

Getting to poor OCR source (which was what I originally responded to). Given the many likely permatations of errors of the types "long- term", "long - term", "1ong-term", "long'-term", etc., etc., and errors of the type "*m-ty", bulk ignores become increasingly unhelpful as the number of errors being the same becomes increasing unlikely with the rattyness of the OCR. One is going to have to rely on much to and froing from the reference scans or paper book to do justice to the book.

There is much else that could be said about the risks of bulk ignores or substitutions, but I will constrain myself and I am sure you are as aware of them as anyone. In the end, one is going to have to get ones nose into the scan or paper book which is the reference.

Originally Posted by Tex2002ans

Side Note: This latest journal I am working on digitizing (~4400 pages, ~2 million words), there were ~18800 hyphens before -> 18428 after fixing (this means ~2% of the hyphens were a mistake.)
That would have taken fracking FOREVER to do one-by-one (it already took me 12 hours to do it the Spell Check List way (including all the time double-checking/fixing the source material, plus doing some code cleanup + other spelling corrections)...

Indeed it might have taken forever (remembering that Kingsley happily wrote "for-ever" ), but it is rather unfair to assume that I would use what you seem to have extrapolated, for the sake of constructing a criticism, into the likes of being my Gold Standard approach for everything including a 4,400 page book.

In the event the largest books I work with are of the likes of official or authorative histories which may run to a meagre 1,200 pages or so, but are complex and can serve as examples. If my source was text then there is no way that I would be cleaning them up in Editor (remembering this forum is about Editor and so that is what my earlier posts confined themselves too) nor be first converting to HTML. If my source was HTML, as it can be when made available from academic websites, for example, then I would have a serious think about how I would go about it and that may likely not be using Editor (nor Sigil, which I don't use now).

In such books one can be led into serious difficulties if correctness is important and one starts relying on bulk ignores and substitutions. Just a simple example is that your example of "long-term" may be used by the book's author but within a quotation "long-term" is incorrectly used by him as the author of that quoted passage (as checking in the reference scan or paper book shows) actually used "longterm" or maybe "long term" (the latter, incorrectly as an adjective). If one's final work is to be a correct rendition one must follow the originally published work unless commissioned to modernise it.

If the book is not a modern one (or is a modern one talking about the past) then the alternative possible hyphenations (together with the various possible spellings of the words hyphenated together themselves) become mind frazzling and well beyond the reach of a simple spell checker as is likely to be found in Editor.

Looking at "long-tongued" as an example, the text may contain "long-tongued" when talking in modern terms but also contain "lang-tongued" which if bulk corrected might be incorrectly so if it was referring to a passage of Walter Scott's work. Furthermore the same book may also include "longtongued" if referring to work from the 16th Century in which case one will have to check if that is correct for the era or work referred to; so even bulk assumptions of non hyphenated words that might be hyphenated are potentially dangerous. (As you may guess, I've been peeking in the OED). So one may see in spell-check that there are "183" instances of "long-tongued" but it may be that there are not, and until one actually looks at each case one does not know.

I'll leave it at that and make no further comment about the matter, I've said more than plenty and am well past being boring

[Rev. Bob]

Here's a different "doesn't save changes" example that, IMO, is a rather serious bug.

For whatever reason, calibre doesn't like to save the first book I edit in a session. Calibre spins its wheels for several seconds, then says there's some problem overwriting the original file, so the save fails. If I ask Windows, it reports that the book is locked by a calibre process. While that's annoying, it's not the bug in question.

Normally, when a book saves, it does so instantly. OTOH, if I try to close calibre while it's saving, it (quite properly) pops up a box saying, in effect, "Hey, I'm saving here! Want me to close when I'm done instead of right now?" That sounds like a good idea, so I sometimes forget and say yes.

The problem is, if there's a problem saving the book, calibre still closes - with no error message, no hint that the save failed, and no way to recover the work.

Any chance that behavior could be modified? Perhaps even offer a config option to save with a modified filename if overwriting the original file fails? ("Hey, I couldn't overwrite book.epub, so I saved it as book-1.epub instead.")

[kovidgoyal]

There's no guarantee that that trying to save a file as book-1.epub would work, what is calibre to do if that fails? try book-2.epub, then book-3.epub and keep on trying forever? At some point it has to give up. If you tell it to quit anyway, it will give up after the first failure, which is a logical point to give up. If something on your computer keeps on locking files, then you need to find and fix that something, or you need to get into the habit of not clicking yes, quit anyway.

[Rev. Bob]

Originally Posted by kovidgoyal

There's no guarantee that that trying to save a file as book-1.epub would work, what is calibre to do if that fails? try book-2.epub, then book-3.epub and keep on trying forever?

That's certainly one option, yes. If I try to copy a file where it already exists, no operating system I've used this decade has had a problem with figuring out an alternate filename that isn't taken. Windows uses "book (Copy).epub", or "book (Copy) (n).epub" as need be. Even a simple dialog box saying "hey, there was a problem" and prompting for a new filename (ie. shunting over to the Save As logic) would be helpful.

For that matter, simply not deleting the temp file if the "copy over original" operation fails would be better than nothing. After all, we already know that's a valid filename.

Originally Posted by kovidgoyal

If something on your computer keeps on locking files, then you need to find and fix that something,

Unfortunately, according to my computer, "that something" is calibre itself. From memory, "calibre working process" is the specific name given.

Originally Posted by kovidgoyal

or you need to get into the habit of not clicking yes, quit anyway.

So you're saying that you see nothing wrong with "close when finished saving" closing with no error message, abort option, or recovery option in the event that the save is unsuccessful? Because that goes against pretty much every principle of user interaction that I'm familiar with.

[kovidgoyal]

Originally Posted by Rev. Bob

That's certainly one option, yes. If I try to copy a file where it already exists, no operating system I've used this decade has had a problem with figuring out an alternate filename that isn't taken. Windows uses "book (Copy).epub", or "book (Copy) (n).epub" as need be. Even a simple dialog box saying "hey, there was a problem" and prompting for a new filename (ie. shunting over to the Save As logic) would be helpful.

Sigh, read the very first sentence in my post again. Here I'll mark the relevant part in bold for you:

There's no guarantee that that trying to save a file as book-1.epub would work

Or in other words, while what you suggest would work for your special error mode, it will not in general work. Learn to think beyond you own limited horizons.

So you're saying that you see nothing wrong with "close when finished saving" closing with no error message, abort option, or recovery option in the event that the save is unsuccessful? Because that goes against pretty much every principle of user interaction that I'm familiar with.

Yes, because what you are suggesting would leave the user with no way to quit the program short of force killing it. You need to broaden your experience with user interaction principles.

And yes, special casing your particular error mode is possible, trying another name if the first name fails. That does not solve the general problem of what to do when saving fails, only your special error mode. And one of the basic principles of designing robust software is to not litter the code with endless special cases.

In any case, I am done talking with you, again. All the best.

[eschwartz]

I am personally inclined to think that no one should be saving a file by closing the program and waiting for the "save me first" prompt.

If you need to save a file, in any program, you should use the Save/Save As, and then close after you have responsibly made sure your work is saved.

In my biased opinion, all programs should have the "save then close" dialog replaced with "you have unsaved work, are you sure you want to exit". Force the user to make use of the appropriate save dialog.

[Rev. Bob]

Originally Posted by eschwartz

I am personally inclined to think that no one should be saving a file by closing the program and waiting for the "save me first" prompt.

Fully agreed. The situation I'm running into is where I've hit "save", the program has returned control to me (usually an indication of success, but in calibre's case an indication that the Save Job has started), and since I'm done, I try to close the program. I'm most emphatically NOT using "close program" to reach a save dialog.

Originally Posted by eschwartz

In my biased opinion, all programs should have the "save then close" dialog replaced with "you have unsaved work, are you sure you want to exit". Force the user to make use of the appropriate save dialog.

And in my biased opinion, "close after X" should not close if X generates an error. In that scenario, the program should abort the "close" instruction and instead display the error, so the user has a chance to react to it. I don't think that's an outrageous or even unusual request.

Heck, I'd even be happy with a way to disable "close when done" entirely in the preferences - set it once instead of being vulnerable to slip-ups Every. Single. Time.

[Rev. Bob]

Originally Posted by kovidgoyal

There's no guarantee that that trying to save a file as book-1.epub would work

And if it doesn't work, the program should not automatically close. It should display an error message and give the user a chance to react, not gleefully trash his work in silence.

Originally Posted by kovidgoyal

what you are suggesting would leave the user with no way to quit the program short of force killing it.

Except, of course, to go through Save As to save it elsewhere, or explicitly opt to Close Without Saving...both of which are options that exist.

All I'm really asking is that, in a very general sense, "close when jobs finish" should give the user a chance to respond to any errors generated by those jobs before closing. If there are none, great! Go ahead and close silently! But if there are...odds are that the user needs to know about those errors, so they should be notified and have a chance to react. That's not asking for a lot, and I don't get why you're stomping off in a huff over it.

[eschwartz]

Originally Posted by Rev. Bob

Fully agreed. The situation I'm running into is where I've hit "save", the program has returned control to me (usually an indication of success, but in calibre's case an indication that the Save Job has started), and since I'm done, I try to close the program. I'm most emphatically NOT using "close program" to reach a save dialog.

And in my biased opinion, "close after X" should not close if X generates an error. In that scenario, the program should abort the "close" instruction and instead display the error, so the user has a chance to react to it. I don't think that's an outrageous or even unusual request.

Heck, I'd even be happy with a way to disable "close when done" entirely in the preferences - set it once instead of being vulnerable to slip-ups Every. Single. Time.

Hmm, I think I see what you mean. FWIW I don't believe "close when done" should be an option in the average UI toolkit (together with Save and Exit).

[Rev. Bob]

Originally Posted by eschwartz

Hmm, I think I see what you mean. FWIW I don't believe "close when done" should be an option in the average UI toolkit (together with Save and Exit).

I can see the value of it, but I'd rather not have it than have it suppress errors.