0.4.904 (0.5 beta) Available

[meme]

Originally Posted by Ahmad Samir

Or just do it like Firefox and KWrite, when a search reaches the end of the document (page in Firefox) clicking "Next" again will make the search wrap, select the first match in the document and show a message indicating that:
- Firefox: "Reached end of Page, continued from top" on the FindBar
- KWrite: "Reached bottom, continued from top" on the status bar.

I've no objection against wrap-around - but I would want more than a status bar notice if it were used. Like Libre Office and I think Word, a dialog should pop up if wrap-around is used to avoid missing the status bar notice.

[theducks]

Originally Posted by meme

I've no object against wrap-around - but I would want more than a status bar notice if it were used. Like Libre Office and I think Word, a dialog should pop up if wrap-around is used to avoid missing the status bar notice.

I could live with that

[meme]

Originally Posted by Ahmad Samir

Or just do it like Firefox and KWrite, when a search reaches the end of the document (page in Firefox) clicking "Next" again will make the search wrap, select the first match in the document and show a message indicating that:
- Firefox: "Reached end of Page, continued from top" on the FindBar
- KWrite: "Reached bottom, continued from top" on the status bar.

Ah, overthinking it. Yes, wrap around with a dialog and always searching from cursor would work fine. Except Count which would always apply to the whole document or all files - which is reasonable.

[user_none]

I've changed it to start a new search from the cursor position instead of using a cache with every match location. There won't be any difference in behavior in normal modes.

In Regex mode the difference is the start (or end) of the text is computed based upon where the cursor is located instead of the previous match if we searched for every non-overlapping match from the beginning of the document. This means the count of all occurrences won't necessary match the number of times find next will match. This is because one match could have multiple matches inside of it. Meme's example illustrates this.

Due to the way regex's work I can't figure out how to do them in reverse for find backward. So find backward is the original method of start at the beginning of the document and move forward finding all non-overlapping matches until the cursor position is reached. The last match is then used. In Meme's example, if you put the cursor at the end of the document the larger matching block is selected instead of the smaller one that is closer to the end. This is because the smaller match is inside of the larger one which is matched first.

[WS64]

I think this (or at least something similar) was mentioned already, but anyway:

When you have code like
H<sub class="small">2</sub>O
in your text and you change from BV to CV it changes the text to
H <sub class="small">2</sub>O

[Serpentine]

Originally Posted by meme

As theducks said, some folks scare easily of CV, or rather, most users starting with Sigil will use BV. And I'm not sure why you would prevent its use there since it doesn't cause any additional issues and works fine.

I really, really can't see why someone who understands regex would want to use it in BV, I simply do not understand how someone who understands regex would then be scared off by using it in the code view. I understand that regex is unfriendly and that people who might be scared off by code and such require a nice way to search - and that is why I think that BV should be limited to the simple searches only (You might notice that I also asked for the case sensitive options to be returned).

Consider doing a replacement in BV, what advantage do you have over doing it in CV?
I cant think of any outside of the unlikely or low-frequency 'matching in tag/attributes'.
Then let us take this to the other side, what do I gain by limiting regex to the code view?
I will not frustratingly have clicked into a view, and after counting BV, matched nothing and incorrectly assumed that something is correct.
BV matches do not preserve tags, the text matched, if used in replacement - will be stripped of formatting, in many cases this would be rather bad(think calibre's spammed spans).
One less (and imho most likely very seldomly well used) use case to provision for (see this very bikeshed).

Originally Posted by meme

Why is it best with regex not to use a cursor position? Maybe I'm just missing something.

Meh, the reasons are pretty minor, I guess its one of those things which I dislike since it's inefficient in both implementation and user interaction.

Most tools use a results cache, avoiding the whole cursor position issue, this also makes the whole model a lot easier to think about.
The next result, if you have moved the cursor in-front of a match, is the same result as the previous match.
If you swap document with the same cache, you are able to hop to the next result without needing to swap back to the document, figure out where the cursor was and then hopefully get the correct next match.

An alternative would be to have a results list: far more friendly, useful and informative than having to flip through new matches sequentially, without moving around.

[user_none]

@WS64, The rename with umlaut issue has been fixed. Turns out the stdio function in Windows cannot handle unicode characters. You have to use Microsofts special _wrename function for unicode support.

[Jabby]

Are you saying that if I set up a Regex expression and get a count and then use this expression to do a F&R I could get a different replace count depending on the cursor position. I would think that sort of thing should be avoided.

That's like saying that it OK to get a different sum from adding a column of numbers depending upon which row you start.

If there is a compelling reason to start a search from the cursor position, I would suggest making it an option.

Regards - John

[user_none]

Originally Posted by Jabby

Are you saying that if I set up a Regex expression and get a count and then use this expression to do a F&R I could get a different replace count depending on the cursor position. I would think that sort of thing should be avoided.

Yes because regexes can be variable length. For example:

start ... stuff ... start ... stuff ... end ... stuff ... end

You can construct an expression to match everything between "start" and "end". Since there is a "start" and "end" nested inside of a "start" and "end" you will get one match if you start looking at the very beginning and a completely different match if you start looking between the first and second "start".

[theducks]

Originally Posted by Jabby

Are you saying that if I set up a Regex expression and get a count and then use this expression to do a F&R I could get a different replace count depending on the cursor position. I would think that sort of thing should be avoided.

That's like saying that it OK to get a different sum from adding a column of numbers depending upon which row you start.

If there is a compelling reason to start a search from the cursor position, I would suggest making it an option.

Regards - John

My reason for a Count is to try and predetermine how many places I will affect.
Not how many I will effect in the end.

[Jabby]

Originally Posted by theducks

My reason for a Count is to try and predetermine how many places I will affect.
Not how many I will effect in the end.

My reason for a count is a sanity check. For instance: If I am making a regex change to chapter headings, I run a count to see if my regex expression count matches the number of chapter that I know I have. If it does not match, I do a one by one "find next" to see what steps I need to take to get the results I want.

Wanting the "find" count to match the "replace" count is like wearing a belt and suspenders. With my bad eyes, a nervous mouse hand and a lack of regex experience, I am more than prone to error.

I'lll bet that sometime, in the future, someone will report the non-matching counts as a bug. Any takers?

Regards - John

[user_none]

As long as you step through from the beginning of the document the search will match count. For the most part they will always match it all comes down to how the regex is constructed and if you start your find in the middle vs the beginning of the document.

[Jabby]

Originally Posted by user_none

As long as you step through from the beginning of the document the search will match count. For the most part they will always match it all comes down to how the regex is constructed and if you start your find in the middle vs the beginning of the document.

I understand all that. What I don't understand is why you want to start from the cursor position. Is there a compelling reason to make the change? What are the benefits?

If you are saying that the F&R will no longer wrap then we have an entirely different kettle of fish. Then it becomes necessary to make it optional and give it a check box.

Regards - John

[meme]

Originally Posted by Jabby

I understand all that. What I don't understand is why you want to start from the cursor position. Is there a compelling reason to make the change? What are the benefits?

If you are saying that the F&R will no longer wrap then we have an entirely different kettle of fish. Then it becomes necessary to make it optional and give it a check box.

Start what from the cursor position?

It would be interesting to list exactly what the old Sigil did for F&R/Count and what the new code does - with regard to cursor position/wrap around, etc. (does it wrap in the old version or just start from the start?) I'll have to install the old copy and compare it.

I think the cases where count won't match will be limited to occasional regex's. But the possibility of always from cursor with option wrap for everything (despite my comment about count before) is something to keep in mind - but a checkbox might be needed to avoid having to ok it every time someone doesn't remember to go to the start of the document/files. Of course, if in practice the updated code works for almost everyone there might not be a need to change it.

[user_none]

Originally Posted by meme

Start what from the cursor position?

What is taken into account for searching.

Originally Posted by meme

It would be interesting to list exactly what the old Sigil did for F&R/Count and what the new code does

4.x and 3.x behave the same as the newly (not yet released) beta code. The currently released 5.x betas have a different behavior.

Originally Posted by meme

with regard to cursor position/wrap around, etc. (does it wrap in the old version or just start from the start?) I'll have to install the old copy and compare it.

Wrapping is currently not implemented.