0.4.904 (0.5 beta) Available

[meme]

Originally Posted by user_none

It doesn't match from your cursor location. It matches from the beginning of the text. So since (?s)Stoker.*?Release matches from line 9 to 31 that is the only match.

The .*Release also has the same issue because it starts matching a the beginning of the line so if your cursor is at the start of class then you're already past the start point for the match.

So what this really comes down to is how to determine what a match is. I'm looking at the entire document beginning to end right now. Would it be better to do a forward and then backward search from the cursor position?

The reason I went with a beginning to end search is you will always get the same count no matter where you are in the document. Going by cursor position (as shown with this example) you will get different matching results depending on where your cursor is due to the nature of regex's including or not including text.

I think we're talking about 2 different things. One is Count (ie count all items on the current page). For this it seems reasonable to include the entire document regardless of where your cursor is. (Same with Replace All).

The other is Find. For this it makes sense to start the Find Next from where your cursor is - even if in the middle of a line. And since you aren't using wrap-around, to search from the cursor to the end of the document. Same with Find Previous (from the cursor) and Replace Next/Previous.

Clearly you do search from the cursor sometimes - if I just have a line like "Say hello and hello and hello again" and you do a search for just "hello" then you will find the first one, and a Find next will find the next one, etc. But a search for ".*hello" won't match anything if your cursor is not at the start of the line. So maybe the ".*" is just a special case. It wasn't anything I needed to use, just a test.

If its just a choice about different approaches then I think the others who use Sigil more need to comment. But it does look odd to me when it looks like it should match, but doesn't.

[Serpentine]

I've had a few instances of searching not matching things which it should, I havent taken notice of the cursor position however. I will try to remember next time. I do think that checking the search strategy would be a wise idea, ideally it should always search entire document(s), nothing position based.

I also recall an issue with replacing/removing css using CDATA in the header of pages, it seems to be regenerated as soon as it is removed - rather annoying if you have already moved it into the stylesheet. If you manually remove it then it seems to be happy. I will try make a reproducible example of this.

[meme]

Originally Posted by Serpentine

I've had a few instances of searching not matching things which it should, I havent taken notice of the cursor position however. I will try to remember next time. I do think that checking the search strategy would be a wise idea, ideally it should always search entire document(s), nothing position based.

Could you expand on this. How do you do find next/previous if its not position based?

If you mean it should wrap around, that has its own issues (do you highlight something that spans from the end to the start of the document, or do you just prompt to search from the start...).

[meme]

Minor item since it doesn't affect users, but if you run sigil from the command line so that you see error messages, you get messages like this when switching to CSS or Image tabs since signals are being connected for them when the tab type doesn't support them:

Warning: Object::connect: No such slot ImageTab::Undo()
Warning: Object::connect:  (sender name:   'actionUndo')
Warning: Object::connect: No such slot ImageTab::Redo()
Warning: Object::connect:  (sender name:   'actionRedo')
Warning: Object::connect: No such slot ImageTab::Cut()
Warning: Object::connect:  (sender name:   'actionCut')
Warning: Object::connect: No such slot ImageTab::Copy()
Warning: Object::connect:  (sender name:   'actionCopy')
Warning: Object::connect: No such slot ImageTab::Paste()
Warning: Object::connect:  (sender name:   'actionPaste')

[theducks]

Originally Posted by meme

Could you expand on this. How do you do find next/previous if its not position based?

If you mean it should wrap around, that has its own issues (do you highlight something that spans from the end to the start of the document, or do you just prompt to search from the start...).

I am with you.
Search forward should respect position.
Search Backward should respect position.
Search should Never Wrap as it would negate Start Position (especially with 'All' )
I commonly use S&R to find all AFTER the only one to leave alone.

[user_none]

Originally Posted by meme

Could you expand on this. How do you do find next/previous if its not position based?

When you do a search the entire document is searched. Every match from beginning to end is then cached. Later searches (if the term or content hasn't changed) reference this cache so the search doesn't have to be run again.

So basically it does a count (entire document) then uses the cursor position to determine which match is closest (forward or backward directional searching). This is instead of starting a new search from the cursor position and ignoring everything before.

[user_none]

Originally Posted by meme

Minor item since it doesn't affect users, but if you run sigil from the command line so that you see error messages, you get messages like this when switching to CSS or Image tabs since signals are being connected for them when the tab type doesn't support them:

This has been there for the longest time and other then not being very pretty it doesn't hurt anything.

[user_none]

Originally Posted by dynabook

Will going back to QT 4.7.4 allow use with Snow Leopard?

Yes it does.

[meme]

Originally Posted by theducks

I am with you.
Search forward should respect position.
Search Backward should respect position.
Search should Never Wrap as it would negate Start Position (especially with 'All' )
I commonly use S&R to find all AFTER the only one to leave alone.

Well who new search was so open to interpretation

I'm with you for 2 1/2 points:
For Current File or All HTML Files:
Search Forward should respect position, always. No wrap is ok as it is, although the option of a dialog to start at beginning (of file/files) would be ok. If it doesn't consistently respect position it will be confusing.
Search Backward should respect position, always
Replace Forward should respect position, always
Replace Backward should respect position, always
But:
Count (All) should count everything in the document(s) irrespective of position. i.e. as if the cursor was at the start.
(Replace) All should replace everything in the document(s) irrespective of position.

Unless I'm missing something, this is how Sigil does Count All, Replace All at the moment. It does not depend on position. I understand the use case for Replace All Forward (e.g. author's names/titles), but then I think a separate Replace Forward button would be needed (or some other dropdown/checkbox option). Count All/Replace All should do just that - ALL, not just some.

Originally Posted by user_none

When you do a search the entire document is searched. Every match from beginning to end is then cached. Later searches (if the term or content hasn't changed) reference this cache so the search doesn't have to be run again.

So basically it does a count (entire document) then uses the cursor position to determine which match is closest (forward or backward directional searching). This is instead of starting a new search from the cursor position and ignoring everything before.

Ah, that makes sense, at least from an programmer/performance point of view. And it probably only affects Regex as plain text searches (and possibly on certain regexes, maybe even ones no one uses). I'm not sure how that can be explained to a user though. I mean, obviously you just explained it and it is what it is, but I don't know how you could expect a user to figure that out if they come across it: it searches from the cursor, most of the time? Is the performance hit that great in typical usage? Or is this how its usually done and this is a rare unrealistic example? (I just check Libre Office Writer's Find&Replace with regex set and it correctly finds .*hello even if the cursor is not at the start).

[theducks]

Sigil does something that no other editor I have ever used does: It works on a SET of documents (sections).

All needs to have many meanings. It all depends on context.


Count (informational), should count Current: the entire current tab (html, CSS, NCX, OPF) contents
or
Count All: All Text (HTML). No cursor start point, start at the first file in the Text section in the Book browser to the last file in the Text section.

I disagree that Search(& Replace) should ever wrap.
Instead of Wrap, have a tick: 'Start at First (file/line, depending on mode:current or All HTML)'. the default is start from here

this adds some confusion as to what happens with the next file in the sequence (All HTML Mode).

The reason for using All rather than just repeating Replace Next
is quantity

So let me toss an idea An ALL repeat Limiter setting (default infinite).

Repeat: n occurrences on This Tab, Repeat n Tabs, Repeat n NEXT occurrences, Where n is a spin wheel count

[meme]

Originally Posted by theducks

All needs to have many meanings. It all depends on context.

Count (informational), should count Current: the entire current tab (html, CSS, NCX, OPF) contents
or
Count All: All Text (HTML). No cursor start point, start at the first file in the Text section in the Book browser to the last file in the Text section.

I disagree that Search(& Replace) should ever wrap.
Instead of Wrap, have a tick: 'Start at First (file/line, depending on mode:current or All HTML)'. the default is start from here

this adds some confusion as to what happens with the next file in the sequence (All HTML Mode).

The reason for using All rather than just repeating Replace Next
is quantity

So let me toss an idea An ALL repeat Limiter setting (default infinite).

Repeat: n occurrences on This Tab, Repeat n Tabs, Repeat n NEXT occurrences, Where n is a spin wheel count

Hmm, how to add options without adding complexity. It seems the new F&R is an attempt to remove complexity so I imagine changing it too much is something to avoid. I've seen some editors with so many checkboxes its overwhelming.

Regardless of the options, its a separate issue from searching from the cursor position forward (or sometime searching from the closest previously cached entry). Whatever is done it must be consistent and obvious.

Interesting that you list Count with no cursor start point, yet for find/replace its configurable. If there is a global tickbox, then it needs to apply to everything (e.g. from cursor should be both for Count or Replace).

I'm not so keen on a spinwheel, but if you are really looking for something like this level of control, then the dropdown could be expanded without adding to the size of the F&R box, e.g.
Look in

• Current File from cursor
• Current File from start of file
• All HTML files from cursor.
• All HTML files

It would apply to Find, Replace, Count, Replace All for consistency. Find /Replace Previous is a complication - should start of file also be end of file, or just not find anything if current file from start of file selected.

Or is it sensible to change this to a couple of checkboxes - a little quicker to operate (a tick is one move, select dropdown and change to value is two), e.g.:

[] Look in all HTML files [] Find from start of file

Of course its up to user_none - I can imagine this close to .5 that he wouldn't want to change much.

[Serpentine]

I still have no idea why the regex mode can be used in anything besides the codeview.

And when using regex, it's still best to not use any cursor position.

For normal text searching, then I think that should work as it currently does.

[theducks]

Originally Posted by Serpentine

I still have no idea why the regex mode can be used in anything besides the codeview.

And when using regex, it's still best to not use any cursor position.

For normal text searching, then I think that should work as it currently does.

Why not? Fix a spelling error. Delete "Page ###"

True these could be done in CV, but some folk scare easily
(But would these folk even dare to use scary REGEX )

[Ahmad Samir]

Originally Posted by meme

Hmm, how to add options without adding complexity. It seems the new F&R is an attempt to remove complexity so I imagine changing it too much is something to avoid. I've seen some editors with so many checkboxes its overwhelming.

Regardless of the options, its a separate issue from searching from the cursor position forward (or sometime searching from the closest previously cached entry). Whatever is done it must be consistent and obvious.

Interesting that you list Count with no cursor start point, yet for find/replace its configurable. If there is a global tickbox, then it needs to apply to everything (e.g. from cursor should be both for Count or Replace).

I'm not so keen on a spinwheel, but if you are really looking for something like this level of control, then the dropdown could be expanded without adding to the size of the F&R box, e.g.
Look in

• Current File from cursor
• Current File from start of file
• All HTML files from cursor.
• All HTML files

It would apply to Find, Replace, Count, Replace All for consistency. Find /Replace Previous is a complication - should start of file also be end of file, or just not find anything if current file from start of file selected.

Or is it sensible to change this to a couple of checkboxes - a little quicker to operate (a tick is one move, select dropdown and change to value is two), e.g.:

[] Look in all HTML files [] Find from start of file

Of course its up to user_none - I can imagine this close to .5 that he wouldn't want to change much.

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.

[meme]

Originally Posted by Serpentine

I still have no idea why the regex mode can be used in anything besides the codeview.

And when using regex, it's still best to not use any cursor position.

For normal text searching, then I think that should work as it currently does.

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.

Why is it best with regex not to use a cursor position? Maybe I'm just missing something. (Obviously cursor position has to be taken into account at some point, otherwise find next will always just find the same text as the find will always start from the beginning of the file...)