Possible To-Do List for Future Sigil Releases Post Sigil 1.8

[KevinH]

Unfortunately not. The actual epub is opened into a temp area (with all files copied in) and Sigil processes it from there. Saving a file or save-as takes those files and recreates the epub. It does not replace members in the existing epub it only overwrites the epub file. So file modification dates in the epub/zip are meaningless.

To track changes you will either need to use Sigil's checkpoints and in its diff capability, or git or possibly effectively do what github does and hash/checksum each file to see which are changed in the zip from a prior version to know what changed outside of Sigil.



Checkpoints would probably be easiest, but if your work process goes outside Sigil, then git or a python script to compare two versions of an epub using checksums would be helpful.

[Tex2002ans]

Originally Posted by democrite

Would it someday be possible to preserve modification dates within the EPUB, e.g. if a file hasn't been modified, keep the old date? Such may be hard to keep track of, I don't know. I'm not sure if I am the only one, [...].

I believe Calibre's Editor does this.

(Although I haven't checked the internal modification dates in a very long time.)

It was helpful when you could open a book, then see certain chapters with original (individual) modification dates:

- 2021.12.12 = Chapter01.xhtml
- 2018.01.01 = Chapter02.xhtml
- 2021.12.12 = Chapter03.xhtml

You'd know that some sort of fix/correction was done within those chapters only. (Sigil, for as long as I remember, always adjusted every file within the EPUB with the current date/time.)

I just did a modification date analysis a few months ago on a massive Churchill book.

Hitch had some issues with the original ebook release (2018), and I dug up later versions of the ebook (2019) to see differences.

[KevinH]

That is what Checkpoints and its diff capabilities are for. Try it out. As long as you do not delete the git repo underneath Sigil it will happily show only modified files by name and if text based, it will show you exact changes since the last checkpoint or before any two checkpoints.

[roland1]

re; to dos: Here's something not so glamorous that may also not affect anyone else, but...

The mouse cursor doesn't always show up in the "find/replace" window. At least not for me. That means if I have to backspace to delete something, I can't see the cursor as its moving back.

I'm using SIGIL on a Power Mac in Sierra (Why not? It works) and so it may not be an issue with other people on their systems. But if this is an issue for some, then at least I've mentioned it.

[KevinH]

It was an issue a few releases back that we worked around in master previously. It sounds like the fix got lost somehow.

[Tex2002ans]

Originally Posted by KevinH

The new re library is just to update to a rewritten version 2 of the pcre library from version 1 that Sigil uses. That is internal but that change should be invisible to end users.

I was digging around. Here's all the extreme technical details on PCRE2:

https://github.com/PhilipHazel/pcre2
https://pcre.org/current/doc/html/index.html

For some reason, a few months back, when I was searching, it was so hard to find info. Now, first thing that popped up...

Strange things are afoot!

[democrite]

Originally Posted by KevinH

... The actual epub is opened into a temp area (with all files copied in) and Sigil processes it from there. Saving a file or save-as takes those files and recreates the epub. It does not replace members in the existing epub it only overwrites the epub file. So file modification dates in the epub/zip are meaningless.

To track changes you will either need to use Sigil's checkpoints and in its diff capability, or git or possibly effectively do what github does and hash/checksum each file to see which are changed in the zip from a prior version to know what changed outside of Sigil.

That modification dates inside a zip file, or specifically epub, are not useful, I strongly disagree. Of that too, maybe little I say will have an effect for the moment, but I ask to merely think of it and I hope someday such really changes. That dates are not kept really prevents me from continued use of Sigil with one specific EPUB. After initial creation or modification, I use instead BBEdit so I can keep track of mod dates, as for other reasons.

If Git or some other similar software is better suited to tracking changes, that could be. Myself, I merely use the version history from some cloud storage to revert any unwanted changes. As for modification dates, for example, how many commercial EPUBs many of us have, and use Sigil for some common mods such as fixing typos, editing the TOC, or other. Often, I may just restructure to Sigil norm, rename the files, edit the TOC, etc. In such cases, maybe I could note such, but it is much easier to just keep the mod dates. So for example, if images or certain files are not modified, many years later I can see the original dates of the EPUB files for those not modified. Or if the image mod dates are modified, I may know if did something to them such as compress. Or if I add a font, I can know the mod date of the font compared to the copy of it I have elsewhere. There are possibly many reasons why keeping each and every EPUB elsewhere such as in Git is to me impractical.

In the case of commercial EPUBs, as publishers may later re-publish with corrections, I can easily compare the date, know when the EPUB was made from mod dates, and then if there's an update, know that it is an update from the dates, and possibly compare or replace if needed.

Maybe there are other cases. To me, not changing the mod date of a file if it's not modified is a given and what should be done. Yet I understand others at the moment disagree. Zip files, archives in general, backup, and so forth, whatever, for the file system itself, mod dates I consider important.

I do not really know C++, and particularly I have not tried to look at the Sigil code, yet I may start and continue. I think this is the place where mod dates are set?

https://github.com/Sigil-Ebook/Sigil...tEPUB.cpp#L174

I am not familiar with that particular parameter, and if it contains info other than moddate. I tried to look at API docs, yet couldn't find much description of that parameter yet. Is passing null enough? Yet I am also not familiar with the rest of Sigil. Perhaps file modification state is not kept, or maybe it is. After the EPUB is unarchved to a temp folder, perhaps merely saving any files if needed, and not modifying others is enough. Or maybe more is required so that is part of the resistance to such change. I don't know. I just hope someday. If I were to attempt it myself, are there other larger changes needed?

We have at least one other that finds such useful.

[KevinH]

You misunderstood. I am not saying that file modification dates in the epub are not useful. I am saying the way Sigil recreates the entire epub makes them useless to you.

Have you tried Sigil's internal git based Checkpoints/Compare toolbar and tools? It really will show you what has changed quite easily inside Sigil. Outside Sigil file hashing is the best way to detect changes in files if modification dates can not be trusted.

Yes, earlier in that export epub code you can see where the file info is built that is written to the epub. Storing the epub fileinfo values somehow on import, then checking for changes on writing them out with stored values if unchanged might work. So you would need to extend the Resource.cpp base class in some way to store that info into the resource for each file.

[roland1]

re; page split functions: Today I was doing some fast and furious keyboard work using shortcuts and later realized that I had accidentally chopped 3 of my chapters off at the word where I was trying to set the index marker.

The culprit was my pressing return with the shift key still pressed down from the previous keyboard command.

I then went to prefs and removed the default "split page" commands so that I wouldn't keep doing this accidentally. I think, just as a safety precaution, that those commands might be better located away from the "busy" zone or perhaps left blank in favor of keeping them just as icons on the interface.

May sound trivial, but not when it happened to me on several occasions today.

[KevinH]

As the user controls their own shortcuts settings, those who have that issue can easily make it the way they want.

Just like those that have developed 10 years of muscle memory for how to invoke it via the current shortcut can leave it where it is.

[roland1]

I was thinking in terms of doing newbies like me a favor and not really thinking of the old guard who knows the folly of clicking whence they should not click.

When I start learning a program, my first action is not to change the key commands in preferences. That's why I mentioned it.

[KevinH]

Understood but I am very very reluctant to change default keyboard shortcuts given their long history.

[roland1]

Orthodox Sigilianism. I'm okay with that.

[theducks]

Just think about the poor 'Help desk' (like us MR folk) trying to instruct:

Just Click the Pig icon (and you changed it to a Turkey), so no Pig.
. Leading to frustration on both parties

Then there is the never ending Windows 'cosmetic' changes, or moving (or burying) system tools.

[democrite]

Originally Posted by KevinH

You misunderstood. I am not saying that file modification dates in the epub are not useful. I am saying the way Sigil recreates the entire epub makes them useless to you.

Have you tried Sigil's internal git based Checkpoints/Compare toolbar and tools? It really will show you what has changed quite easily inside Sigil. Outside Sigil file hashing is the best way to detect changes in files if modification dates can not be trusted.
...

As a mention, I cannot overemphasize enough how much I hope someday, and how much it means to me (and maybe others). I'd think despite unzipping to a temp folder, archive dates could be preserved, and if edit state is tracked, perhaps just such files would have the date changed on save.

It may be a little while before I get to trying it myself; maybe I could figure it out with enough effort, yet maybe the change isn't do bad, if merely you thought too it to be important and were willing.

As for using checkpoints, as mentioned, I may just update metadata, restructure to Sigil Norm, compress files (typically outside w/external tool), edit CSS, subset fonts, edit TOC, or other, or some combination of all or a few or one. E.g., for commercial epubs, I may merely make a few changes or substantially change. It would be difficult to checkpoint every EPUB. Imagine doing such for one's entire calibre library? And if someday Sigil is no longer the tool of choice? Years later, if I wish to know if I've compressed images or what is the possible (corrected) revision of some purchased EPUB (dates is one indicator), or have some other question, much can be determined, at least enough for me for various reasons, that such dates are so significant. You yourself seemed to have suggested mod dates are too important.