Data type search only searches text before cursor position instead of full search string

[gemesa]

Describe the bug
Seems like the data type search is only triggered when the cursor is at the end of the search string. More precisely, it searches for the string located before the cursor. E.g. if int is in the search box and the cursor is between in and t then it looks for matches containing in. This behavior is annoying when I modify a longer string multiple times and need to move the cursor to the end to trigger the search each time. Maybe this is intentional but I have never seen a search box behave like this.

To Reproduce
See above.

Expected behavior
The position of the cursor is ignored while searching for strings.

Screenshots
See above.

Attachments
N/A

Environment (please complete the following information):

• OS: Linux 6.14.5-300.fc42.x86_64 amd64
• Java Version: Eclipse Adoptium 21.0.4
• Ghidra Version: 11.4
• Ghidra Origin: locally built

Additional context
N/A

[Wall-AF]

It can be very helpful. Maybe a configuration option would be better?

[dragonmacher]

The design was intentional. Users can arrow left and right to control what is shown in the list. If you think of the feature as a 'starts with' filter instead of a 'search', then it makes sense the way it is now.

I'm not opposed to changing the behavior if we can make it better. The typical use case is to start typing, with the results narrowing as you type. What is your use case where you would like different behavior?

[gemesa]

I have some Rust types like Option<&[&[u8]]>, &[&[str]], &[Argument<&str>] (just some examples) and usually I dont remember the full type, just some parts of it. So I start typing in the search box and if I am lucky, the type I need pops up and I choose it. Sometimes I struggle to find it, e.g. I forget to add an extra & or [] pair in the search box at the proper position in the type. In this case I need to go back, add extra & to a different place, move the cursor at the end of the type to see if it matches. If not then maybe remove the previously added & and add an extra [] pair somewhere and move the cursor once again to the end of the string. Just some examples. When going through this "type finding iteration", moving the cursor to the end each time is just extra annoyance.

I dont know if this is clear or not. Maybe my workflow is just completely wrong but this is how I do it now.

[gemesa]

I have been thinking and I think substring matching would be the best solution for my use case. E.g. I type in the search box argument and &[Argument<&str>] (and all other types containing argument) pops up. Currently the type has to match from the start.

[dragonmacher]

I can see a 'contains' search being very useful. (You can get that now, albeit clunkier, by hitting the browse button and typing in the tree's filter.)

The 'starts with' lookup allows us to perform very fast searches. Switching to a contains could be much slower if the universe of data types in the tool is large.

I will explore ways to toggle between both modes.

[gemesa]

Ah okay. I didnt know it behaves differently when I click on Browse. It is good enough for me, thanks.