Two advices on Sigil's "Find & Replace".

[The_book]

After reading Scripted "Find & Replace"? and using Sigil, now I have two advides on Sigil's "Find & Replace".
First, "Case Sensitive" can be a opintion like DotAll and Wrap. It is not an independent mode. In "Normal" or "Regex" we can both have "Case Sensitive".
Second, "Saved Searches" can save more than now, saving the opintions like "Normal" or "Regex", DotAll and Wrap, or left blank, which means do not change the "Find & Replace" mode.

[DiapDealer]

Your first suggestion already exists. "Normal" is case-insensitive, and "Case Sensitive" is (Normal) Case Sensitive. Regex is case-sensitive by default, but has its own case-insensitivity option built into it. Why would we reinvent that particular wheel? So yes... you already have complete and independent control over case (in)sensitivity in both modes.

[DiapDealer]

As for the second suggestion, it's not a question of how easily it could be implemented. It's a question of how best to explain to users with extensive Saved Search libraries that we broke them. Introducing new fields would be next to impossible to do while maintaining backward compatibility with existing SS libraries. Meaning we run the risk of potentially damaging existing libraries (at the extreme), or at the very least, tell users that they need to manually massage their existing preference files to work with the new format that will be required to store more fields per saved-search entry.

I'm sure that some ways around the backward compatibility issue could be found, but the point is that it's a huge factor when considering how to implement such a feature expansion.

[The_book]

Originally Posted by DiapDealer

Your first suggestion already exists. "Normal" is case-insensitive, and "Case Sensitive" is (Normal) Case Sensitive. Regex is case-sensitive by default, but has its own case-insensitivity option built into it. Why would we reinvent that particular wheel? So yes... you already have complete and independent control over case (in)sensitivity in both modes.

Regex has its own case-insensitivity option built into it.
Sorry for I know nothing about this. Where is the opinion?
And it is for readable, I think. Nromal compare to Regex, and they both have a case-sensitive opinion. I think it's more intuitive。

[The_book]

Originally Posted by DiapDealer

As for the second suggestion, it's not a question of how easily it could be implemented. It's a question of how best to explain to users with extensive Saved Search libraries that we broke them. Introducing new fields would be next to impossible to do while maintaining backward compatibility with existing SS libraries. Meaning we run the risk of potentially damaging existing libraries (at the extreme), or at the very least, tell users that they need to manually massage their existing preference files to work with the new format that will be required to store more fields per saved-search entry.

I'm sure that some ways around the backward compatibility issue could be found, but the point is that it's a huge factor when considering how to implement such a feature expansion.

I know now, I may go ot see the sourse code to check it.

[DiapDealer]

Originally Posted by The_book

Regex has its own case-insensitivity option built into it.
Sorry for I know nothing about this. Where is the opinion?

And therein lies the problem. If you knew more about regex, you would already know why there's not going to be any checkbox to make a regexp case-insensitive. (?i) makes a regular expression case-insensitive.

Originally Posted by The_book

And it is for readable, I think. Nromal compare to Regex, and they both have a case-sensitive opinion. I think it's more intuitive。

Not going to happen. I'm not going to waste time trying to make regex more "intuitive" for people who don't know regex.

As already mentioned, you already have complete and independent control over case sensitivity in both normal and regex modes. You don't need features added to Sigil. You just need to become more fluent with regex.

https://www.regular-expressions.info/

[The_book]

Originally Posted by DiapDealer

And therein lies the problem. If you knew more about regex, you would already know why there's not going to be any checkbox to make a regexp case-insensitive. (?i) makes a regular expression case-insensitive.


Not going to happen. I'm not going to waste time trying to make regex more "intuitive" for people who don't know regex.

As already mentioned, you already have complete and independent control over case sensitivity in both normal and regex modes. You don't need features added to Sigil. You just need to become more fluent with regex.

https://www.regular-expressions.info/

Ok. It's just I uesd to use regex in javascript or python, which have a flag argument which can control case sensitivity, DotAll or other things. So I think case sensitivity is a opinion like DotAll and I don't know to use (?i).
And now I learn it. Thank you.

[DiapDealer]

You can also use (?-i) to disable case insensitivity. PCRE regex makes it possible to apply/remove case (in)sensitivity to portions of regex expressions. Meaning one could have case sensitive and case insensitive portions in the same expression. Which means that advanced regex users would actually have to sacrifice functionality if a simple on/off option were used to control regex case (in)sensitivity.

[Tex2002ans]

Originally Posted by The_book

It's just I uesd to use regex in javascript or python, which have a flag argument which can control case sensitivity, DotAll or other things. So I think case sensitivity is a opinion like DotAll and I don't know to use (?i).
And now I learn it. Thank you.

Calibre Editor's "Case Insensitive" applies to Regex searches.

So this text:

This is a test Case case.

with this Regex:

[c]ase

By default, Sigil/Calibre will only match lowercase "case".

If you check the Case Insensitive box, Calibre matches both "Case" and "case". (I haven't looked in source, but I assume Calibre secretly adds (?i) to the Regex if the box is checked?)

[DiapDealer]

Calibre typically uses the Barnett regex Python module (where Sigil uses PCRE). I don't know if the Barnett module allows the granular use of the case insensitive flag to control portions of expressions or not (the standard python re module does not). I think it depends on how the module is compiled. If it doesn't, a global "switch" makes more sense.