Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Showing all matches during a search #579

Merged

Conversation

tangledhelix
Copy link
Collaborator

This is a proof-of-concept for #564.

To try it out, do a search and you should see all matches highlighted in a subtle color, and the currently-active match in a more prominent color. You can go to the next match, etc, and the highlighted match will hop around but the inactive ones will all remain visible.

This is not production quality and has known bugs (for instance, the match highlights are not removed unless you start a new search, because I haven't gone through to find all the places they'd need to be cleaned up yet).

Is this on the track we were thinking? Any notes about the basic functionality before I go tidy up all the cobwebs?

One final note - the current match is also selected, as it has always been, but there's a more prominent highlight applied to the same range, so it's not colored like a selection typically is. But it is selected, and you can check that by typing over it, that should work the same as before.

@windymilla
Copy link
Collaborator

I've had a quick play - it looks it's on the track I was thinking, and I couldn't break it.

I tried to stress it by searching for . with regex on, so it highlighted every character in yellow. It took a little while, but given it was a crazy test, it wasn't unusable. When I searched for the letter e (again, not something you'd do in real life) it highlighted a lot of letter es, and there was a small but noticeable delay for each search. When I searched for the (which is about the most common thing that is at least vaguely realistic that someone might search for) any delay was very short. Normal behavior on my part didn't show any delays.

Searching forward and backward seemed to work, as did wrapping round the end of the file.

Of course, colors would need to be discussed.

To be honest, I haven't had time to look at the code. Is it adding tags through the whole file (I suspect yes), or is it detecting the start & end visible viewport lines and just highlighting between those? Does it use similar to the highlighting code?

@tangledhelix
Copy link
Collaborator Author

Of course, colors would need to be discussed.

Yes, and for this PoC I just realized I didn't add a dark mode yet (I think)... I'll try to add those tonight for @srjfoo to review.

To be honest, I haven't had time to look at the code. Is it adding tags through the whole file (I suspect yes), or is it detecting the start & end visible viewport lines and just highlighting between those? Does it use similar to the highlighting code?

At the moment it's just something I rushed out for a PoC, so it's tagging the entire file, I think it even removes and recreates all the tags each time you go to the next occurrence. There are a bunch of things that need refactoring, and others that need to be implemented; e.g. I don't think I check "search in selection" yet.

And as you probably saw, it's not very smart about removing the tags; it only does so if you run a new search.

@tangledhelix
Copy link
Collaborator Author

Pushed some changes:

  • No longer using a special tag for the active match; just use the normal selection highlight
  • For inactive matches (not the current one), improved (I hope) color for light mode
  • For dark mode, added colors designed for it

I was hoping to use the relief border to outline matches. Unfortunately I can't seem to find a way to control the color of the border, it's always black. Therefore in dark mode, it's as if it's not there. (You can tell it is if you look very closely.)

I might drop the relief/border for this reason. It's not consistent among the themes.

Note that if the text window is not focused, the main match will be different than if it's focused. (As in any case where you are using a selection.) But the inactive matches highlight the same regardless of focus. Please share any feedback about that.

This is still buggy, doesn't un-highlight unless you search again, etc... all I did was improve coloring for now.

@windymilla
Copy link
Collaborator

I was hoping to use the relief border to outline matches. Unfortunately I can't seem to find a way to control the color of the border, it's always black. Therefore in dark mode, it's as if it's not there. (You can tell it is if you look very closely.)
I might drop the relief/border for this reason. It's not consistent among the themes.

I think you're right - if you have relief style "solid", you can't control the color. The other styles choose sensible colors for the theme though, I think. The screenshots below are with style "ridge", which also needs borderwidth at least 2 for it to show the "up" and the "down" of the ridge (discovered through bitter experience during GG1 coding).

image
image

@windymilla
Copy link
Collaborator

But the inactive matches highlight the same regardless of focus. Please share any feedback about that.

I think this is fine. Since the inactive is a subtle highlight, I think it's OK that it's the same in an unfocused window.

@tangledhelix
Copy link
Collaborator Author

Bug: if "In Selection" is checked, and a text region is selected before searching, only the active highlight works, and the inactive highlight is not applied.

@tangledhelix
Copy link
Collaborator Author

I think you're right - if you have relief style "solid", you can't control the color. The other styles choose sensible colors for the theme though, I think. The screenshots below are with style "ridge", which also needs borderwidth at least 2 for it to show the "up" and the "down" of the ridge (discovered through bitter experience during GG1 coding).

I tried ridge with border 2 based on this post and I like it. For the sake of exploring the rabbithole, I tried all the others, but most were not as good, so I came back to ridge.

For certain letters, it interferes / overlaps the letter just a bit. Mostly those with a straight left vertical bar (R, B, E, etc.) But I think it's quite usable and I'm not going to worry much about it. Some of the other reliefs overlapped even more, so the left bar of the letter almost appeared to be outside of the highlight.

Screenshot 2024-12-18 at 6 33 37 PM Screenshot 2024-12-18 at 6 33 45 PM Screenshot 2024-12-18 at 6 34 06 PM Screenshot 2024-12-18 at 6 34 11 PM

@tangledhelix tangledhelix force-pushed the search_tagall branch 2 times, most recently from 22e1c3a to 5cd7fa3 Compare December 21, 2024 04:42
@tangledhelix tangledhelix force-pushed the search_tagall branch 3 times, most recently from 34e0f00 to 741aa04 Compare January 2, 2025 21:22
@tangledhelix
Copy link
Collaborator Author

Bug: if "In Selection" is checked, and a text region is selected before searching, only the active highlight works, and the inactive highlight is not applied.

This is not so much a bug in the code as the product of a choice I made to piggyback on count_clicked() to get the search done. I'll need to reimplement how the search is done to work around that.

@tangledhelix tangledhelix force-pushed the search_tagall branch 2 times, most recently from 0eb52b8 to d1db679 Compare January 5, 2025 22:25
@srjfoo
Copy link
Member

srjfoo commented Jan 7, 2025

I decided to do some poking, and thought I'd comment in case it's useful.

@windymilla, is "in selection" is supposed to work for a general search. If it is supposed to work, it's broken in master. From the positioning in the search form, it looks like it applies only to count, find all, and the replace alls. If that's intended, that's fine, and I don't think that showing all matches within a selection is necessary? Unless simple find within a selection is planned? Besides which, you've got the issue of highlighting within highlighting.

This may be limited to Macs, because of the way the search form works: If I search and press the return or the search button, the search form remains active. That means that the actual active selection is pretty difficult to see, because the color of the selection is the background selection color. It's actually not too bad, though, because the line and column numbers are highlighted.

I really like the border around the non-active matches, and the fact that they're slightly dimmed. They stand out nicely, whether foreground or background.

Just so I could guarantee lots of matches, I chose "to" as one of my search terms. It looks like I did a "find all" on it, because it's got the orange spotlight color. And I can't clear it. Running a subsequent normal search on the to show the other matches on the page leaves "to" spotlighted.

Unrelated to this PR, but for "find all" + "in selection" -- the only thing that allows one to see the highlighted search terms is if one clears the selection after one does a find all, because the highlighting of the selection overrides the spotlight.

@windymilla
Copy link
Collaborator

@windymilla, is "in selection" is supposed to work for a general search. If it is supposed to work, it's broken in master. From the positioning in the search form, it looks like it applies only to count, find all, and the replace alls. If that's intended, that's fine, and I don't think that showing all matches within a selection is necessary? Unless simple find within a selection is planned? Besides which, you've got the issue of highlighting within highlighting.

That's behaving as it should, and I don't have any plans for simple find within selection

This may be limited to Macs, because of the way the search form works: If I search and press the return or the search button, the search form remains active. That means that the actual active selection is pretty difficult to see, because the color of the selection is the background selection color. It's actually not too bad, though, because the line and column numbers are highlighted.

It's not limited to Macs. GG1 is the same in that it keeps the focus in the search dialog. The problem for you if it didn't is that IIRC in order to search again, you'd need to click once to get focus back and then again to click the Search button, so 2 clicks for every search. However, GG1 is different in that when search it doesn't highlight the match with a "normal" selection, it uses a thing a bit like our "spotlight". This has the disadvantage IMO in GG1 that if you switch focus to the main window, and type, it doesn't replace the found match (although we could maybe make it do that, I guess, even if we used our own tag, rather than normal selection). Notepad++, for example, does select the found match, as does VS code. If you dismiss the search box, the latest match remains as a normal selection, and typing replaces it.

However, we could override the theme and force the inactive selection background color, if we were concerned about it being too subtle.

I really like the border around the non-active matches, and the fact that they're slightly dimmed. They stand out nicely, whether foreground or background.

Yes, they look good, though this (unlikely case - I searched for def and there are several above one another) looks slightly odd

Just so I could guarantee lots of matches, I chose "to" as one of my search terms. It looks like I did a "find all" on it, because it's got the orange spotlight color. And I can't clear it. Running a subsequent normal search on the to show the other matches on the page leaves "to" spotlighted.

That's expected & deliberate behavior for all spotlights. They remain until you do something else that is spotlighting, or you close the dialog that did the spotlighting (Find All dialog in this case). We could possibly argue that Find All is a special case and the spotlight should be cleared when you do another search, but you could also argue for keeping it as it is.

Unrelated to this PR, but for "find all" + "in selection" -- the only thing that allows one to see the highlighted search terms is if one clears the selection after one does a find all, because the highlighting of the selection overrides the spotlight.

Hmm - not sure what @tangledhelix thinks about that. We definitely want selection as higher priority than spotlight for most cases, as reported by Rick previously when you're trying to fix something that has been spotlighted. Attempting to swap priorities seems dangerous, so does that mean that for Find All only, it needs its own spotlight (which looks the same to the user, but is actually higher priority than selection)? Thinking about swapping priorities, you'd have to have calls to put selection to the top whenever a selection is made, and put spotlight to the top whenever spotlight is shown - seems as though it would be likely to go wrong.

@tangledhelix
Copy link
Collaborator Author

Unrelated to this PR, but for "find all" + "in selection" -- the only thing that allows one to see the highlighted search terms is if one clears the selection after one does a find all, because the highlighting of the selection overrides the spotlight.

Hmm - not sure what @tangledhelix thinks about that. We definitely want selection as higher priority than spotlight for most cases, as reported by Rick previously when you're trying to fix something that has been spotlighted. Attempting to swap priorities seems dangerous, so does that mean that for Find All only, it needs its own spotlight (which looks the same to the user, but is actually higher priority than selection)? Thinking about swapping priorities, you'd have to have calls to put selection to the top whenever a selection is made, and put spotlight to the top whenever spotlight is shown - seems as though it would be likely to go wrong.

No to swapping priorities.

Maybe when the user navigates to a match from one of these dialogs (Find all, WF, etc,) the navigation could de-select whatever's selected and make the match just jumped to the new selection (or else have no selection at all).

@srjfoo
Copy link
Member

srjfoo commented Jan 11, 2025

Unrelated to this PR, but for "find all" + "in selection" -- the only thing that allows one to see the highlighted search terms is if one clears the selection after one does a find all, because the highlighting of the selection overrides the spotlight.

Hmm - not sure what @tangledhelix thinks about that. We definitely want selection as higher priority than spotlight for most cases, as reported by Rick previously when you're trying to fix something that has been spotlighted. Attempting to swap priorities seems dangerous, so does that mean that for Find All only, it needs its own spotlight (which looks the same to the user, but is actually higher priority than selection)? Thinking about swapping priorities, you'd have to have calls to put selection to the top whenever a selection is made, and put spotlight to the top whenever spotlight is shown - seems as though it would be likely to go wrong.

No to swapping priorities.

Maybe when the user navigates to a match from one of these dialogs (Find all, WF, etc,) the navigation could de-select whatever's selected and make the match just jumped to the new selection (or else have no selection at all).

My observation was just that, an observation, and the only place I observed it was when doing something "in selection" plus another operation. I hope I didn't seem to be suggesting a solution, or even suggesting that there is an easy solution. Perhaps all we should do is document that where there are multiple overlapping highlightings, something has to override. And list the priorities.

@tangledhelix
Copy link
Collaborator Author

My observation was just that, an observation, and the only place I observed it was when doing something "in selection" plus another operation. I hope I didn't seem to be suggesting a solution, or even suggesting that there is an easy solution. Perhaps all we should do is document that where there are multiple overlapping highlightings, something has to override. And list the priorities.

If you select some text and then do a "find all," and click around the matches, if there are matches in your selected region, then you can't see when you jump to them. To me it feels basically like a bug, so IMO it should be addressed. Since I don't think we should change the highlight ranking, and I don't think this behavior is good either, the obvious (to me) solution is just deselect whenever we navigate to a match like that. I haven't checked, but there may even be one method that is used to do such jumps and we could put the code in that one place...

@tangledhelix
Copy link
Collaborator Author

the navigation could de-select whatever's selected and make the match just jumped to the new selection (or else have no selection at all).

I guess no selection at all - because if we did a select, then we'd lose the point of having a spotlight style in the first place...

@windymilla
Copy link
Collaborator

If you select some text and then do a "find all," and click around the matches, if there are matches in your selected region, then you can't see when you jump to them. To me it feels basically like a bug, so IMO it should be addressed. Since I don't think we should change the highlight ranking, and I don't think this behavior is good either, the obvious (to me) solution is just deselect whenever we navigate to a match like that. I haven't checked, but there may even be one method that is used to do such jumps and we could put the code in that one place...

That sounds like a good plan. Since selection is cleared if the user clicks in the text window, it would make sense if they navigate to the text window via a match from a checker dialog.
Adding
maintext().clear_selection()
at about line 933 in checkers.py (just after it positions the insert cursor) should do it.

@tangledhelix, do you want to do that in this PR - I don't think it's related - or shall I do a separate one?

@srjfoo
Copy link
Member

srjfoo commented Jan 11, 2025

If you select some text and then do a "find all," and click around the matches, if there are matches in your selected region, then you can't see when you jump to them. To me it feels basically like a bug, so IMO it should be addressed. Since I don't think we should change the highlight ranking, and I don't think this behavior is good either, the obvious (to me) solution is just deselect whenever we navigate to a match like that. I haven't checked, but there may even be one method that is used to do such jumps and we could put the code in that one place...

That sounds like a good plan. Since selection is cleared if the user clicks in the text window, it would make sense if they navigate to the text window via a match from a checker dialog. Adding maintext().clear_selection() at about line 933 in checkers.py (just after it positions the insert cursor) should do it.

@tangledhelix, do you want to do that in this PR - I don't think it's related - or shall I do a separate one?

If the search is "in selection", you still want to see results from within the selected range -- it's not clear to me whether you mean "clear selection" or "clear selection highlighting"?

@windymilla
Copy link
Collaborator

If the search is "in selection", you still want to see results from within the selected range -- it's not clear to me whether you mean "clear selection" or "clear selection highlighting"?

It actually does both - clears selection and highlighting. However this is after you have clicked "Find All", so it won't alter which results you see. My suggested solution is equivalent to doing a Find All (which then highlights the first match) clicking in the main window (which will clear the selection) then clicking back on the first match in the Find All dialog.

@tangledhelix
Copy link
Collaborator Author

@tangledhelix, do you want to do that in this PR - I don't think it's related - or shall I do a separate one?

I'd rather you do a separate one. I'll probably be tinkering with this one a while yet, and I'm away a bit right now busy with some remodeling work (remodeling house, not code 😄 )

@windymilla
Copy link
Collaborator

Spotlight/selection priority issue added.

@tangledhelix tangledhelix force-pushed the search_tagall branch 5 times, most recently from fbaba19 to 2f1f16b Compare January 19, 2025 02:54
@tangledhelix
Copy link
Collaborator Author

This should be working now, and I'll turn off the Draft mode. It's ready to review.

Testing notes:

  • Search as you normally would. The active match will look like a normal text selection (because that's what it is).
  • Other matches to your search should be highlighted with a surrounding rectangle and is meant to be a subtle coloring to be visible, but not stand out too much to get in the way visually.
  • Just as before, the active match, being a selection, will appear differently if the text window is focused vs. not focused. The new highlights do not change appearance in response to focus.
  • If you change to a different search, the highlights should adjust properly.
  • These highlights will persist until one of the following happens:
    • A new search is done; then they are cleaned up and replaced by the new search's highlights.
    • The Search dialog is closed (either with Cmd-W or equivalent key, or clicking the close button on the dialog)
    • The "Remove Highlights" command is run
    • (I am open to also having the Esc key do this but I didn't implement that.)
  • Currently the entire file is tagged when the search button is clicked, as opposed to showing matches in the viewport on every redraw. I'm interested in any observations about poor performance during what you think are normal searches. I know earlier there were stress tests done; those are important to do, but ultimately those are outliers so I'm more interested in the behavior for more normal types of searches.
  • The new highlighting should work in the split view.

I believe I changed the colors since earlier reviews - so please mention whether the colors seem proper or not.

Copy link
Collaborator

@windymilla windymilla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks great.

Your <Destroy> binding works better than the general one in ToplevelDialog, so I'll steal that idea once this is merged: New issue here

However, one small problem if the main window is destroyed before the Search dialog:

  1. Open the Search dialog
  2. Close the main window without first closing the Search dialog
  3. On Windows, at least, that gives an exception as the Search dialog tries to clear highlighting from maintext which has already been destroyed.
  4. A suitably placed if maintext().winfo_exists(): should fix it.

When searching, jump between matches as before when navigating matches, but also highlight all other matches for user convenience.

Highlights removed when:
- search is changed to a new search string
- "Remove Highlights" command is run
- Search dialog is closed

Fixes DistributedProofreaders#564
@tangledhelix
Copy link
Collaborator Author

However, one small problem if the main window is destroyed before the Search dialog:

  1. Open the Search dialog
  2. Close the main window without first closing the Search dialog
  3. On Windows, at least, that gives an exception as the Search dialog tries to clear highlighting from maintext which has already been destroyed.
  4. A suitably placed if maintext().winfo_exists(): should fix it.

Same exception on Mac (FWIW). Should be fixed in the latest commit.

@@ -2902,8 +2928,14 @@ def highlight_selection(
tag_name, match.rowcol.index(), match.rowcol.index() + "+1c"
)

def remove_search_highlights(self) -> None:
"""Remove highlights for search"""
if maintext().winfo_exists():
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @tangledhelix - I misled you. I think this fix would actually be better if it said

        if self.winfo_exists():

If you agree, please change it. If you think it doesn't matter, don't worry. I'm going to approve anyway now.

Copy link
Member

@srjfoo srjfoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if the following are something to be concerned about, but thought I'd mention them.

  • Selected text shows cursor position, which is not the case for manually selecting text. Mentioning it because it's a visual inconsistency (and because I was the one making such an issue about it not being needed 😁).

  • When switching panes in split screen mode, the "Search" button re-selects the last selected match from before the switch, if switching back and forth between top and bottom. This is true whether using the button or using cmd+g on a Mac -- don't know if it does the same on Windows. Mentioning it because it may or may not be something that will confuse users. It doesn't do it when searching backwards, which gave me the clue as to why it's happening -- it's related to my first point, above. Since the cursor is placed at the beginning of the selected word, it's "found" again when the search is re-done.

Should these be fixed before this gets merged?

(I closed the main window without first closing the search dialog, and confirm that it did not generate an exception.)

@srjfoo
Copy link
Member

srjfoo commented Jan 23, 2025

Hm ... apologies -- when I did the review earlier, I apparently marked it "request changes". I hope my note was clear enough that I'm not asking for changes if y'all don't agree with me, but I thought I'd go ahead and mention it, anyway.

@windymilla
Copy link
Collaborator

windymilla commented Jan 23, 2025

  • Selected text shows cursor position, which is not the case for manually selecting text. Mentioning it because it's a visual inconsistency (and because I was the one making such an issue about it not being needed 😁).

I don't think this is related to this PR (i.e. I've observed it in master), or possibly we're seeing something different. AFAICT the situation is that in the main text window, the cursor never shows for a selection regardless of whether it's manually selected or via Search. In the peer (bottom half) the cursor always shows for a selection regardless of whether it's manually selected or via Search. Can you confirm whether that is what you're seeing @srjfoo, or if not, what needs to be done to reproduce it. Anyway, what I've described is definitely a bug, so I've entered an issue

  • When switching panes in split screen mode, the "Search" button re-selects the last selected match from before the switch, if switching back and forth between top and bottom. This is true whether using the button or using cmd+g on a Mac -- don't know if it does the same on Windows. Mentioning it because it may or may not be something that will confuse users. It doesn't do it when searching backwards, which gave me the clue as to why it's happening -- it's related to my first point, above. Since the cursor is placed at the beginning of the selected word, it's "found" again when the search is re-done.

This is not related to this PR (it's in master), so if we think it's a problem, it should go in a separate issue.
The current S/R code has the following comment:

Start from current insert point unless following are true:
We are searching forward;
Current insert point is at start of previously found match;
Start of previous match is still selected (or it was a zero-length match)
If all are true, advance to end of match.

I suspect that Current insert point is at start of previously found match; is the part that is not true, because you've done a search in the lower half of the text window (for example), so the previously found match is not the match that was found in the upper half, which is the one you want to "find next" from.

As for the solution, I'm of the opinion it isn't that important. You can probably see why my algorithm appears to make sense. It's trying to detect that you have done a search, and are now doing another search, and you want the search to find the next one, not find the same one again. GG1 doesn't have the same issue. However GG1 does some stuff where it tries to move on one character before searching, so you can also get weird behavior there.

One idea I've just thought of is...
when you've done the above checks and are ready to do the search, you do the search and see what text matches. If the text that matches is exactly the text that was already selected, then advance to the end of the match. However, I can still envisage cases where that would behave "oddly", but maybe not in a RL situation.

Any thoughts welcome.

@srjfoo
Copy link
Member

srjfoo commented Jan 24, 2025

  • Selected text shows cursor position, which is not the case for manually selecting text. Mentioning it because it's a visual inconsistency (and because I was the one making such an issue about it not being needed 😁).

I don't think this is related to this PR (i.e. I've observed it in master), or possibly we're seeing something different. AFAICT the situation is that in the main text window, the cursor never shows for a selection regardless of whether it's manually selected or via Search. In the peer (bottom half) the cursor always shows for a selection regardless of whether it's manually selected or via Search. Can you confirm whether that is what you're seeing @srjfoo, or if not, what needs to be done to reproduce it. Anyway, what I've described is definitely a bug, so I've entered an issue

Yes, that's exactly it. The found word in the peer pane shows the cursor at the beginning of the found string.

  • When switching panes in split screen mode, the "Search" button re-selects the last selected match from before the switch, if switching back and forth between top and bottom. This is true whether using the button or using cmd+g on a Mac -- don't know if it does the same on Windows. Mentioning it because it may or may not be something that will confuse users. It doesn't do it when searching backwards, which gave me the clue as to why it's happening -- it's related to my first point, above. Since the cursor is placed at the beginning of the selected word, it's "found" again when the search is re-done.

This is not related to this PR (it's in master), so if we think it's a problem, it should go in a separate issue. The current S/R code has the following comment:

Start from current insert point unless following are true:
We are searching forward;
Current insert point is at start of previously found match;
Start of previous match is still selected (or it was a zero-length match)
If all are true, advance to end of match.

I suspect that Current insert point is at start of previously found match; is the part that is not true, because you've done a search in the lower half of the text window (for example), so the previously found match is not the match that was found in the upper half, which is the one you want to "find next" from.

As for the solution, I'm of the opinion it isn't that important. You can probably see why my algorithm appears to make sense. It's trying to detect that you have done a search, and are now doing another search, and you want the search to find the next one, not find the same one again. GG1 doesn't have the same issue. However GG1 does some stuff where it tries to move on one character before searching, so you can also get weird behavior there.

One idea I've just thought of is... when you've done the above checks and are ready to do the search, you do the search and see what text matches. If the text that matches is exactly the text that was already selected, then advance to the end of the match. However, I can still envisage cases where that would behave "oddly", but maybe not in a RL situation.

Any thoughts welcome.

Let me describe what I'm doing:

  • enable split pane
  • Choose a common word to search on so you have lots of testing material for going forwards or backwars 😁
  • Search a few times in the top pane
  • Move focus to the peer (bottom) pane and scroll down in the file comfortably past (or earlier than) the selection in the top pane, and place the cursor
  • Use "find" or "find again" to find the next occurrence, and then find a few more.
  • Then flip back to the top pane and find again. The last found word from before you switched to the peer pane will be selected again.

Example:

In my "Land Mammals" test file, I searched for the word mammals, case insensitive. In the top pane, I ended with the occurrence on line 404, then switched to the peer pane and found next until I got to line 1489, then switched back to the top pane, and used cmd+g to search again. Before proceeding to the next match (which is on line 409) the occurrence on line 404 was "found" again. I think this is because the cursor (even though invisible) is implicitly located at the beginning of the string.

This does not happen when searching backwards, presumably because the cursor (whether hidden or not) is at the beginning of the string, and when searching for the next (i.e. previous) occurrence, the same word is not scanned again.

Is this any help, or have I just confused the issue more?

And no, it doesn't need to be fixed in this PR, yes, it's in master. I just wanted to make sure that the issue was acknowledged. My question in my above comment was just asking if y'all think it needs to be. Approval coming up shortly.

@windymilla windymilla merged commit baa5384 into DistributedProofreaders:master Jan 24, 2025
1 check passed
@tangledhelix tangledhelix deleted the search_tagall branch February 13, 2025 00:09
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants