And in Code View, I would expect "sigil_split_marker" to appear to be just as light/dark as any other html attribute value. They're all set by the same preference.

Thank you,

A little tweaking, and my new borders look great.

Brent

This new version is blazing fast compared to the previous one. My computer is a beast; 16 cores/32 threads, 64 gig of ram, and the previous version ran like molasses.

Absolutely fantastic performance improvements. Reports, Syntax Highlighting, Preview. :thumbsup::thumbsup:

But there have been a few regressions introduced along the way too.

One Spellcheck List issue was already adjusted for next release—1.6.1:

- "In spellcheck do FindSelectedWord only if double-clicked to speed paging"

* * *

The Issue

When used on a very large EPUB (~1.6 million words), Tools > Spellcheck > Spellcheck was sluggish, with noticeable delays between clicks/highlights.

These were the timings in my VM:

- Sigil 1.6.0: ~1.4 seconds
- Sigil 1.5.1: ~1.4 seconds
- Sigil 0.9.14: <0.5 seconds
- Calibre 5.19: Instant

Note: In your typical-sized ebook, these steps barely take a perceivable amount of time.

VM Note: Windows 10 + 2 cores + on an external hard drive.

* * *

If you need an enormous EPUB (~1.3 million words) to poke around in, there's the same one I mentioned in my "monolithic single file" report:

https://mises.org/library/complete-l...orum-1969-1984

If you want it even bigger, just EPUB Merge it with another large ebook. :D

The Steps

While in Spellcheck List (Tools > Spellcheck > Spellcheck)...

Sigil pre-1.6.1

1. Single-click a word in the list. It jumps to the word within Code View.

2. Press Page Down/Up OR single-click any word.

(#.## seconds delay to find/jump within Code View.)

Page Down multiple times, and the delay hits every single time as Sigil searches through Code View.

Sigil 1.6.1+

To mitigate some of this, we settled on:

1. Double-click a word jumps to the word within Code View.

2. Press Page Down/Up OR single-click another word. No jump in Code View.

This allows you to easily make all your adjustments directly in Spellcheck List window (sort columns, Change Selected Word To, Add To Dictionary, [...]) without the need to mess with the code.

Side Note: This double-click jump + single-click stay is the way Calibre's Spellcheck List already works.

* * *

Note: KevinH tested this and couldn't reproduce. No/barely any slowness. Also seems like it would be a huge amount of overhaul for fractional gains.

Here was his explanation to me via PM:

Any of you who have an under-powered device sitting around... maybe test some of these steps too. It'll probably be more noticeable compared to our super fast CPUs/SSDs.

... Although at this point, we're niggling over 1 second... Plus, now with Sigil 1.6.1's already-pushed fix, this 1 second will be buried out of the way. :D

FYI, That fix will probably appear in a 1.7.0 release after a few new features have been added. As for timings, 0.9.14 only searches for a word, not the word and language, so it will be much faster as it does not require any code parsing at all. Sigil, unlike calibre (unless Kovid changed it recently) only finds that word in the specified language so if a common misspelling exists in multiple languages it will just find the one matching the specific language being searched for. So the timings are actually not comparable since they do different things.

Once 1.7.0 is released in a few months (or if people build their own from master) if others see the same timing issues with your test case (that I can not reproduce under macOS) we can revisit things to see if something platform specific is at issue.

I would like to comment on the problem reported by @Turtle91 here.

During pre-1.6.0, released 1.6.0 and current pre-1.6.1 tests (I always have the current private build from master) I noticed this problem many times, but I did not consider Sigil to be guilty, but my old computer (i5-2500K, 16GB).

However, last week I finally bought new equipment (i7-11700, 32GB) and I still have the mentioned problem (Windows 10 Pro).
This is exactly step-by-step:
* I'm opening a new EPUB file.
* I search for a word (the XHTML file with the first finding is opened in a new tab).
* In the Preview window I can see the beginning of the file, although the found word is highlighted in Code View in the middle of the file, far from the beginning of the file.
* If I search for the next word and it appears in the same XHTML file, the Preview window will show the correct place, but if it requires opening a different XHTML file in a new tab, the problem will appear again.

(This is the same situation described by @Turtle91.)

Perhaps this is Windows-only related?

That should be fixed in master. Please try opening a CV tab, clicking on a word to sync to Preview, next open any css tab, then switch back to the html tab you had opened. You should see the word you clicked on and Preview should have properly synced.

That bug (also reported by Turtle91) fix seemed to fix Preview syncing to CV either via click or via sync to search. At least it does for macOS.

Can you reproduce that part of his bug report in current master as well?

Yes.
Especially just a moment ago, I made a fresh build from the master with the latest commits.
Issue exists.

EDIT: After clicking in the Code View window, it works OK.
Only searching (no clicking) does not work.
Of course, I can live with it if you confirm that this action is intentional.
This is strange because - as mentioned above - Find Next in the same XHTML file works fine and I don't need to click anything.

I will try again to reproduce what you are seeing on macOS. But the earlier fix should correct both as it involves opening a new tab resource and having Preview sync to CodeView location in that new tab.

I just want to make sure your master build has that fix for the xhtml->css->xhtml tab sequence sync to Preview fix working.

It is not intentional. The problem is that loading PV from CV and telling it to go to a specific location was working only 60% of the time due to timing issues with sequences of Qt signals.

I thought it was fixed, but I may be wrong.

Just to help track this down, did this used to work in 1.5.1, 1.4.3 or 1.3.0?

Yes. I confirm, that xhtml->css->xhtml fix working.

I will check previous versions and let you know.

1.5.1 – works.
1.4.3 – works.
1.3.0 – works.

So, the async Preview Loading we just added seems to be the issue here.

From reading the code, all CV searches that find something should cause PV to sync, but CV is loading before the asynchronous Preview loading is complete and the scroll to the search location is getting ignored since PV is not fully loaded yet.

I will have to think about how to handle this since we have moved to asynchronous loading of PV.