Head's up for those who build their own.

[KevinH]

Just a head's up for those who build their own.

Given all the changes in native nested selectors and CSS 4, Sigil has opted to move to a completely new css parser, moving away from our old CSSTidy derived one. This new css parser is from lexbor.

See https://github.com/lexbor/lexbor

We are using just their css library, statically built. Sigil needed some slight css parser changes that the lexbor developer has agreed to but since those changes modify its abi, we must maintain our changes until such time lexbor is ready to release a new major version. Inside Sigil this code exists inside Sigil/internal/lexbor along side our gumbo version.

Lexbor also has a nice selector implementation we should take a closer look at and an html whatwg spec compliant parser and dom implementation we could move to when and if gumbo gets long in the tooth.

Next our current source code base uses a number of C++ singleton classes which were in desperate need of an overhaul. So each singleton class and surrounding code has been moved to use the Meyers form of the Singleton which should help speed Sigil startup time because of its lazy loading while more safely cleaning up after itself upon exiting Sigil. This change touches a large number of files in Sigil.

Third, I have borrowed code from the hostile Chinese Sigil-Enhanced fork, that should speed up BookBrowser refreshes. Wish they would have contributed that back since they took all our code and never even let us know but ...

Fourth, I have also modified AddExisting to speed up bulk replacement of image files during AddExisting or our DropZone. This time without breaking anything!

So if you do build your own, please start with a fresh build and fresh cmake run to make sure none of the changed files are missed as many new files have been added.

Lastly if you get a chance please test out the single line css reformat and multi-line css reformat and "go to style" in CodeView to make sure I have not broken anything when interfacing their css parser library to our code. It all seems to work for me but more testing is always welcome.

[DNSB]

In my limited testing using my 512 images test ePub, it definitely feels faster. I haven't seen any other issues but I haven't had the chance to spend that much time testing.

[DiapDealer]

We also have a currently opt-in-only test in place for using the python regex module for Sigil's embedded Python routines instead of the re module (plugins will not currently be included in this test). The regex module more closely matches Sigil's PCRE regex then the built-in re module does. Especially where the Python Replace functions are concerned.

The bottom line is that if you build your own Sigil, and you'd like to opt-in to this testing (setting an environment variable), you'll more than like need to update the regex module used in your Sigil build environment. Anything version 2026.5.9 or newer should be fine.

Users of the official releases can opt-in to the test with no worries. The regex module in the official Sigil releases has already been updated starting with Sigil 2.8.1.

[BeckyEbook]

* Each subsequent use of "Multiple Lines Per Style" shifts the opening curly brace further to the right:

.test      {
  text-align: center;
}

* After using "Multiple" a few times, try "Single" – you'll see that the extra spaces are still there:

.test      {text-align:center;}

[KevinH]

Well that is strange. The selector itself is just not being trimmed on the right for some reason in the new library. I will look into adding something to compensate in our interface code.

Thanks for testing and finding that!

[KevinH]

That issue should now be fixed in Sigil master.

It was not their bug, but my interface bug as I chose to use raw css tokens character data to prevent replacements of escaped strings but did not clean them up before using them.

They are purposely left in raw data as a space after a selector segment but before the end must not be trimmed as it may indicate a compound selector.

FWIW, it was actually a lot of work to properly interface their css parser for our use both because it is a heavy callback design for speed and because it is designed to be actually used inside a browser and simply ignores anything it does not like (which is what the spec tells it to do)!

But in Sigil we need feedback on errors in some way to prevent running a reformat when the css itself is broken in someway, possibly ruining it. And we do not want to change the meaning a whole selector because of a missing ";" at the end of one of the properties values.

Either way, this should now be fixed.

I never thought to repeatedly run the reformatter during my testing. I should have.

Thank you for testing it and finding that bug!

[DNSB]

For those using Windows who are interested in testing the new code including the fix for the issue reported by BeckyEbook, you can download the executable from: Sigil-2.8.1-Windows-x64-Setup.exe.

[KevinH]

Originally Posted by DNSB

For those using Windows who are interested in testing the new code including the fix for the issue reported by BeckyEbook, you can download the executable from: Sigil-2.8.1-Windows-x64-Setup.exe.

Thank you!

[3333]

Hi KevinH,

Greetings from the "hostile Chinese Sigil-Enhanced fork".

English is not my native language, so I'm using translation software.

I actually posted a more detailed reply in the earlier Sigil-Enhanced thread:
https://www.mobileread.com/forums/sh...d.php?t=374448

For some reason, though, my reply does not appear to be visible on the forum. I don't know what happened to it, so please excuse me for repeating some of the context here.

I'm glad to see that the BookBrowser optimization was useful enough to be incorporated into Sigil. You are absolutely welcome to use it.

I did find the description "hostile" rather curious, though.

As far as I know, Sigil-Enhanced has never attacked Sigil, discouraged anyone from using Sigil, restricted Sigil from using our changes, or attempted to compete with the upstream project. What we have admittedly failed to do so far is communicate with upstream early enough.

That is a communication problem, not hostility.

And since code from Sigil has flowed into Sigil-Enhanced, while code from Sigil-Enhanced is now flowing back into Sigil, it seems that the "one-way street" may already have acquired a second lane.

That is exactly how open source should work, in my view.

There is also a useful example of how 3tic-project has handled this exact situation before.

We maintain another project called OrionCrane:

https://github.com/3tic-project/OrionCrane

OrionCrane started as a specialized fork of the Crane Rust inference engine. We created it because we needed an inference engine heavily optimized for models we were training ourselves and for workloads that were quite specific to our own use case.

While that work was still changing rapidly, we developed it separately. We did not expect the original Crane project to absorb every experimental optimization or project-specific decision as soon as we wrote it.

But once the work became mature enough, we extracted the parts that were generally useful and contributed them upstream.

Those contributions were not merely offered — a series of them were merged into Crane. Several of those are now substantial parts of what upstream Crane itself provides and advertises.

So this is not a new philosophy invented in response to criticism of Sigil-Enhanced. We have already followed this development model elsewhere:

specialize first, experiment freely, stabilize the implementation, then separate the broadly useful work and contribute it upstream.

That is also what I intend to do with Sigil-Enhanced.

The project is still highly experimental and specialized, so I have deliberately avoided sending upstream a large number of unstable or niche changes. Once the implementations settle down, generally useful fixes, performance improvements, and implementation findings will be separated and shared upstream.

So I am happy to accept criticism for not communicating sooner.

"Hostile", however, seems a little dramatic for two GPL projects already exchanging useful code — particularly when contributing useful work back upstream is something our other projects have already demonstrated in practice.

[DiapDealer]

My experience of "how open source should work" has been that you fork a repository to create pull requests to contribute to the upstream project--to try and get the changes you envision for it to be incorporated. You only start releasing from your own forked repository if upstream ignores you, or flat-out denies your requests for change.

While not in violation of any of Sigil's licensing requirements; jumping straight to releasing from your own modified fork (with no upstream communication) violates an unwritten top-down flow of open-source development that has been around for decades.

Splintering an opensource codebase just because you wish to start fresh is legally (and probably even morally) fine. But it doesn't conform to the top-down, collaborative, open-source model of development that I grew up with.

So maybe not "hostile" per se. But certainly a bit dismissive. But welcome to the discussion, now that you have chosen to join it.

[KevinH]

Or simply google "hostile fork". It is a recognized term in opensource software development:

AI Overview:
A hostile fork happens when developers copy an open-source project's code to start a new, competing project without agreement from the original creators. This split usually happens because of major arguments over the project's rules, license changes, or future goals.

So Sigil-Enhanced is indeed a "hostile fork" of Sigil as no one from your project previously contacted Sigil, no one offered any bug fixes, no one offered to help, etc.

[KevinH]

But as DiapDealer said, now that you have, "Welcome to the party!".

I have read your earlier post in the other thread. I think I better understand what you are trying to achieve. We would appreciate any real bugs reports you run into that pertain to Sigil, and any bug fixes and or speedups. I doubt Sigil has any plans to change the plugin model to add a live server nor adding mcp supprt. Things like font subsetting that is done only once are better done in plugins.

We found the earlier sigil-modified by chance also. It was also a hostile fork that never reached out to us yet still made official releases. Its code was so out-of-date (still required Qt5Compat lib when Qt will probably start dev of Qt7 within a year or so), broken in many places (pretty-printing of inline tags, no whitespace compression) and even the full emmet spec did not work, while auto-complete was nearly useless because of the short length of most html tags. It also had bugs in its bulk AddExisting work, did not use or duplicated existing code to handle bulk removal, and fixated on drag and drop in the BookBrowser which just complicated that entire code without adding anything over a simple DropTarget region (which is what Sigil eventually did). It also incorporated our existing ePub3-itizer and epub2 converter plugins almost line for line to C++ with no real added benefit over the existing plugins. Plugins are modular by design. It keeps Sigil from getting even more bloated.

[KevinH]

So as long as you contribute back at least bug reports, bug fixes, and speedups, we would be happy to remove the word "hostile" from your fork.

But if I were you, I would definitely spend some time reviewing and fixing the sigil-modified codebase you absorbed to not need or use Qt5Compat and maybe fixing and stripping it back to its essentials changing it to not duplicate existing Sigil features and plugins to keep the degree of maintenance from our underlying Sigil changes to a manageable level going forward. But that is of course your call.

[3333]

Thanks, DiapDealer and KevinH. I appreciate the welcome, and especially the time you have taken to explain your concerns and the way you prefer Sigil to be maintained.

Your comments have also pointed out several weaknesses in our current work, particularly in the code inherited from sigil-modified. The specific examples you mentioned are very useful, and we will review those areas carefully rather than assuming that inherited implementations are correct or worth preserving.

I also understand and agree much better now with the development direction you described for Sigil.

For a mature general-purpose editor, keeping the core focused, avoiding unnecessary complexity and dependencies, and leaving self-contained or one-shot functionality to plugins where appropriate is a sensible maintenance strategy. I can also understand why things such as MCP or a live server do not fit the direction you want for upstream Sigil.

Sigil-Enhanced is currently in a more experimental stage. We are still actively adding, revising, auditing, and testing functionality, and some of those experiments are deliberately specialized for our own workflows.

So for now, we will continue developing and testing those experimental features downstream until their design and implementation become more stable.

Once that work settles down, our next step will be to review the resulting changes specifically from the upstream perspective.

We will separate out the areas you have indicated are useful to Sigil itself — real bug reports and fixes, crash fixes, performance improvements, and other generally applicable improvements — test them against the current upstream codebase, and share appropriate changes with Sigil in smaller, easier-to-review contributions.

The discussion here has been very helpful in giving us a clearer understanding of where upstream Sigil wants to draw the boundary between the core, plugins, and downstream experimentation.

Thank you again for the understanding, the criticism, and the concrete technical feedback. It gives us a much clearer direction for how to work with upstream as Sigil-Enhanced matures.