Sigil-1.9.1 Release

[KevinH]

Well that is not good. CV used to always grab focus but for some reason that has changed.

I will try a few things tomorrow.

Thanks!

Kevin

Originally Posted by icallaci

Running SpellCheck causes the current CV window to lose focus. The cursor moves to the correct spot, but the word is not highlighted until you deliberately click on the main Sigil title bar. Actually, I don't think it is SpellCheck itself that is causing the lost focus, but rather the act of clicking on any of the dropdown menus in the title bar. If you doubleclick on a word in the SpellCheck window, then click on the Sigil title bar so that the word is highlighted, then you doubleclick on another word in the SpellCheck window, the CV window loses focus again, so you end up repeating the sequence over and over. In other words, SpellCheck causes the CV window to lose focus every single time you double-click on a word in the SpellCheck window. I hope this helps.

[icallaci]

Originally Posted by KevinH

Hmm ... but when you then finally click Find, does it work (put focus back in CV to properly highlight or not). If not, I can try force it to give all focus back to CV when Find is run no matter where the Focus is.

I will try that first thing tomorrow.

Thanks!

I was going to say "No, clicking on Find does not restore the focus," but the behavior is a little more complicated. Focus is not restored immediately, but if you continue to click on Find after changing the search direction, then at some point focus is restored and the matches are highlighted. I think the focus is restored when the cursor moves to a new file. If you have multiple matches in one file and change the search direction, then focus is not restored until it finds a match in a different file than the one you started in.

[odamizu]

Originally Posted by PapaKilo

I would be happy to test the changes, but I don't know where to download test builds.

@PapaKilo — KevinH posted link to download test builds in his post #51 above. I quote it here:

Originally Posted by KevinH

... It can be downloaded from my repo here:

https://github.com/kevinhendricks/Bu...OnMac/releases

- Sigil-master-c690f8b-build_num-376-Mac.tar.xz 76 MB

- Sigil-master-c690f8b-build_num-376-Win-Setup.exe

[odamizu]

Originally Posted by KevinH

... I used a suggestion you provided earlier and made the Saved Search "Load Search" button now do the following:

- rebuild the set of searches to run as if you had selected something else and then reselected what you had originally (a SavedSearch Group or single search)

- then had it tell F&R to do a Restart

By adding those two things, then when you use LoadSearch, it will be telling it to also begin the entire current selection of searches from the top again.

Originally Posted by KevinH

... Count All should always count *all* not count from where I am until the end of the set of files to be searched.

Similarly Replace All should always replace *all* and not just replace from where I am now until the end of the set of files to be searched ...

I will track that down and get that fixed and post a new test build tonight. In this way the CountAll and ReplaceAll buttons should be quite clear as to doing what their name actually says.

KevinH! These two fixes (in test build 376) work beautifully at solving all the problems I was grappling with yesterday.

- - -

Like others, I noticed the focus issues, but didn't pay too much attention as I was focused on the Search/Replace issues (pun intended ). Having now spent some time paying attention to focus using test build 376, I am finding the following:

Originally Posted by PapaKilo

#2
Open Saved Searches window click on a saved search.
Click find button in Saved Searches
Item is found but it is NOT highlighted in main window.

I am finding this with test build 376.

Originally Posted by PapaKilo

Open Saved Searches window click on a saved search.
Click find button in Saved Searches
Item is found but it is NOT highlighted in main window.
Click on Replace button in docked Find & Replace dialog.
Item is Highlighted in main window, but is NOT replaced.

This is rather problematic. If you go from Saved Searches window to Find & Replace dialog, it seems you can't replace! Going back to Saved Searches window doesn't work, either. You actually have to move to the next Find then go back in order to Replace that match.

Originally Posted by icallaci

... If I enter something in the Find box and click "Count All" or "Find," everything works as it is supposed to. As soon as I click on the dropdown menu to change the direction of the search, the CV window loses focus and doesn't get it back unless I click in it.

I am not finding this to be the case so far with 376 on Mac.

However, I did find that clicking in the Replace field steals focus from CV window until you click on CV window again:

• Open Find & Replace box
• Enter something in Find field
• Click Find button. Focus goes to CV window and highlights match as expected and desired
• Click in Replace window and input something
• Click Find button, and focus is lost in CV window unless you click on CV window then go back to Find button

Given that I commonly enter text in Find field, then enter text in Replace field, then hit Find button, I will end up with CV window not highlighting matches.

Thank you for all your efforts KevinH. I'm sure this is more than you dreamed could possibly happen when you revamped Find & Replace for 1.9.0.

[Ashjuk]

Originally Posted by DiapDealer

I've not run into any disappearing Book Browser icons, or a partially obscured Well Formed check (which is the normal Validation Dock Widget) on Windows or Linux in my testing. At least not yet.

I have been unable to recreate the partially obscured Well-Formed check problem, so I am starting to think it may have been related to the book I was working on at the time. As that book is now fixed I can no longer use that as a test.

As I said to Kevin it was not a huge issue, as the results pane came to the foreground once the check had completed.

I will report back if I experience it again, but for now I think this can be put down to a rogue book.

[snarkophilus]

@kevinh Using text build 376 on Win 10 build 19043.1415, open a not small epub and

1. type ctrl-f
2. type <p
3. hold down ctrl-g until Sigl crashes (approx 5-10 secoonds)

I have seen Sigil quit before once or twice before (many months ago) when doing some quick repeated ctrl-g but haven't been able to reproduce this. Seems like a simple search and press-and-hold ctrl-g is enough. When run from a cygwin command line which I've been able to capture some Sigil messages before, there are no diagnostic messages; the Sigil process just exits. If there's any debug options I can enable, let me know.

Not sure I'd consider this a show-stopper for the next release, but a) would be nice to fix now that I can reproduce, and b) you're having so much fun in the S&R code now.

[KevinH]

Yes indeed! Too much fun! I'll add it to my bugs to fix list!

Originally Posted by snarkophilus

@kevinh Using text build 376 on Win 10 build 19043.1415, open a not small epub and

1. type ctrl-f
2. type <p
3. hold down ctrl-g until Sigl crashes (approx 5-10 secoonds)

I have seen Sigil quit before once or twice before (many months ago) when doing some quick repeated ctrl-g but haven't been able to reproduce this. Seems like a simple search and press-and-hold ctrl-g is enough. When run from a cygwin command line which I've been able to capture some Sigil messages before, there are no diagnostic messages; the Sigil process just exits. If there's any debug options I can enable, let me know.

Not sure I'd consider this a show-stopper for the next release, but a) would be nice to fix now that I can reproduce, and b) you're having so much fun in the S&R code now.

[Turtle91]

Originally Posted by snarkophilus

@kevinh Using text build 376 on Win 10 build 19043.1415, open a not small epub and

1. type ctrl-f
2. type <p
3. hold down ctrl-g until Sigl crashes (approx 5-10 secoonds)

I have seen Sigil quit before once or twice before (many months ago) when doing some quick repeated ctrl-g but haven't been able to reproduce this. Seems like a simple search and press-and-hold ctrl-g is enough. When run from a cygwin command line which I've been able to capture some Sigil messages before, there are no diagnostic messages; the Sigil process just exits. If there's any debug options I can enable, let me know.

Not sure I'd consider this a show-stopper for the next release, but a) would be nice to fix now that I can reproduce, and b) you're having so much fun in the S&R code now.

This sounds like it could be the same issue I’ve had with Sigil for a long time. I’ll be in the middle of some heavy duty editing - usually replace/find next - and Sigil will shut down. I always thought it was caused by my machine starting a new process when an old one hadn’t finished.

[icallaci]

Originally Posted by Turtle91

This sounds like it could be the same issue I’ve had with Sigil for a long time. I’ll be in the middle of some heavy duty editing - usually replace/find next - and Sigil will shut down. I always thought it was caused by my machine starting a new process when an old one hadn’t finished.

I've seen this too (always or almost always) during a find and replace session, but I could never reproduce it. Sigil will just all of a sudden quietly close without warning. At least it taught me to save early and save often.

[odamizu]

I am not able to reproduce this on macOS 10.15.7. I pressed-and-held ctrl-g for 60 seconds.

That said, I used to get Sigil crashes when doing repeated replace/find in very quick succession (clicking Replace/Find button, not keyboard command). This was a while back. Sent KevinH crash reports at the time. Seems to be resolved on Mac for the most part, though I still occasionally get a stray random crash that I can't reproduce.

Curious: what is the purpose of pressing-and-holding ctrl-g (as opposed to ctrl-g in quick succession). Why press-and-hold?

Originally Posted by snarkophilus

@kevinh Using text build 376 on Win 10 build 19043.1415, open a not small epub and

1. type ctrl-f
2. type <p
3. hold down ctrl-g until Sigl crashes (approx 5-10 secoonds)

I have seen Sigil quit before once or twice before (many months ago) when doing some quick repeated ctrl-g but haven't been able to reproduce this. Seems like a simple search and press-and-hold ctrl-g is enough ...

[KevinH]

I have finally tracked down all of the bugs reported so far except for the fast ctrl-g segfault/crash.

With master I was able to open a huge book and search for "the" repeatedly. I was even able to hold ctrl-g down and get it to repeat as fast as it possible could but never get it to crash. I tried the same with a short book and no crash - just a No Matches Found message constantly flashing. So either this is not an issue on MacOS or I am not doing enough to recreate what you are seeing.

I do hope people report all crashes though. I truly hate apps crashing and there is no reason for it. I want to track down any you are seeing. That said, my macOS Sigil builds have not crashed on me in literally years. So you must be exercising code I rarely use.
Stability should be the first goal of any piece of software. I thought we were there (at least on macOS) but if many of you are reporting a crash there must be something there (but maybe platform specific).

The test builds are build made right now and in half an hour or so, I hope to have a a new (and hopefully close to last) test build for people to try.

[KevinH]

Hi All,

As far as my testing shows, this one seems to fix all of the bugs reported so far (except the icons disappearing and the repeated ctrl-g crash neither of which I can recreate yet on macOS).

The test builds can be downloaded from my repo here:

https://github.com/kevinhendricks/Bu...OnMac/releases

- Sigil-master-1dcef80-build_num-377-Mac.tar.xz

- Sigil-master-1dcef80-build_num-377-Win-Setup.exe


Again thanks to everyone who tests and helps make Sigil better!

I have my fingers crossed!

[odamizu]

KevinH, you are AWESOMENESS

Test build 377 is working great for me

My only comment is cosmetic. Sometimes the line highlight uses the default Line Highlight color (yellow) and sometimes it is gray (default line# Background).

Using Find & Replace dialog:

• Click in Find field and type something, then click Find button — line is highlighted in yellow (default Line Highlight color), match is highlighted in blue
  
  
  
• Click in Replace field and type something, then click Find button — line is highlighted in gray (default line# Background), match is highlighted in blue
  
  

Using Saved Searches window:

• Select saved search and click Find button — line is highlighted in gray (default line# Background), match is highlighted in blue
  
  

Not sure if this is expected behavior or if highlighted line should always be yellow or gray. Not a big deal, but thought I'd mention it in case it interests you.

[KevinH]

Glad to hear bugs have been squashed.

The line highlight colour change is expected. It still indicates if CodeView has focus.

I tried to force focus in earlier test builds but that is a blind alley that was doomed for failure.

So I went back to Sigil 1.5 and 1.7 and watched and noticed that focus was never forced onto CodeView.

Next I went and noticed, that under earlier test builds, matches were actually found and selected but you can not see them anymore due to the inactive (no focus) current line highlighting in CodeView.

I was able to make the active highlighting for selected text properly appear but being active or inactive properly determines the current line highlight colour.

But focus can and does and should move back and forth from Saved Searches, Spellcheck Dialog, Find and Replace, and CodeView.

We could force that to match but I like knowing with a quick glance if CodeView is active (has focus) or not.

Thanks for testing and reporting back!

[KevinH]

Actually, I just remembered the CodeView current line highlight colour is controlled by a Sigil user Preferences setting under Appearance then the CodeView tab.

So a user can make those highlight line background colours match if they so desire.