A request for search box behavior

[rtonsing]

Current GuiGuts behavior is that if the search box is already open while editing, when you copy some text and use Ctrl+F and then Ctrl+V to paste it, the text is appended to the previous search text, because the cursor is positioned at the end of the previous text.

If you do the same in VSCode, Notepad++, Chrome, or Firefox, when you use Ctrl+F the previous text is selected and highlighted, so when you paste with Ctrl+V, it is replaced with the new text, and that is what is searched for.

Not a huge issue, but it is annoying when doing sequential searches with different texts. And it makes sense to be consistent with other applications.

[srjfoo]

In GG2, if what you want to do is start a new search with the selected text, use Ctrl/Cmd+f again, and the selected text is now the new search term. No need to copy/paste unless you want to append to the previous search.

[rtonsing]

I should have made it more clear - the text in the clipboard comes from another window. For instance, when fixing errata, I'm copying text from the browser to find the matching location in GuiGuts.

[srjfoo]

Ah, thanks for the clarification. I'll defer to @windymilla on this. To confirm, the behavior you describe is also seen in BBEdit and Sublime Text (as well as browsers) on Macs.

On the other hand, the GG2 behavior matches the GG1 behavior.

[windymilla]

@rtonsing - I'm up for adjusting behavior slightly to make it more consistent with how other apps work, although for some features, we may want to retain GG's specific behavior as it is used for a very particular job, unlike a general editor.

However, I can't reproduce what you are describing. If the Search dialog is already open, then when I press Ctrl+F, the search text gets cleared from the Search field, and can paste into it. This seems to happen whether focus is currently in the main text area or in the search dialog itself. Please could you detail the specific actions that make it go wrong, so I can investigate further. Thanks.

[rtonsing]

With more testing, this appears to be the current behavior:

Guiguts-py:

1. Click on window title, when some text is highlighted: highlighted text appears in search box, highlighted so Ctrl+V replaces it.
2. Click on window title, no text is highlighted: search box contents is cleared.
3. Click inside window: search box contents is cleared.
4. Click on search box: keeps previous state, if contents was highlighted, it stays so.

GuiGuts (Note that when Ctrl+F is entered, selected text in the main window is unhighlighted, unlike GuiGuts-py.)

1. Same.
2. Click on window title, no text is highlighted: search box contents is highlighted so Ctrl+V replaces it.
3. Click inside window: search box contents is not cleared or highlighted, cursor is at end of contents, so Ctrl+V appends the clipboard sontents.
4. Same.

So my issue is with old GuiGuts #3. GuiGuts-py behaves differently, which is good IMO, please don't change it! This issue can be closed.

At least this may help document the difference, whatever is decided in the future.

[windymilla]

Thanks Robert. I don't intend to change Guiguts 1 behavior, due to the large number of people who are used to it, some of whom would probably find it disruptive. Although my aim is that Guiguts 2 should feel familiar to Guiguts 1 users, it will not be identical in every aspect, such as this more modern search behavior. The GG2 search box has been based on observations of VSCode, Notepad++ and BBedit (on Macs). Of course they are not all fully consistent with one another, so some choices have been made. We will see, when GG2 has more people using it for PPing, whether those choices are the best ones. I'll close this, as you suggest.