Find Usages: Don't automatically select first result

[pgifford]

Description

The first result of Find Usages should not be automatically selected

Use case/motivation

Starting with NetBeans 24, the first result in Find Usages is automatically selected. This is unnecessary and particularly annoying especially considering the new mandatory code preview. The first result in Search Results is not automatically selected so Usages behaves inconsistently.

"Automatically select first usage" should be a preference. Forcing the first result to be selected assumes:

• The first result is likely to be a desired result.
• The user wants to step through the results starting with the first one
• The user has not hidden or disabled the code preview (Usages: Add means to disable code preview #8112)

Related issues

No response

Are you willing to submit a pull request?

No

[mbien]

The first result in Search Results is not automatically selected so Usages behaves inconsistently.

the reason for that is that search and usages use very different infrastructure behind the scenes. Usages is a refactoring (code inspection) and search/replace is not. (but I do get how search and usages can be sometimes used interchangeably)

We could probably check if inspections could skip the "select first item" step, while refactorings would keep doing it like before.

[pgifford]

The first result in Search Results is not automatically selected so Usages behaves inconsistently.

the reason for that is that search and usages use very different infrastructure behind the scenes.

Usages didn’t automatically select the first item in v23 so the inconsistency was introduced in 24. I checked before opening the issue to make sure I didn’t misremember but I’ll double-check next time I’m at work.

[mbien]

Usages didn’t automatically select the first item in v23

because there was no preview.

It is unclear to me what the problem is. If anything, I think we should let the search/replace window also select the first item if the results are known immediately (no async search triggered). This would fill the preview and often result in one click/keystroke less.

[pgifford]

because there was no preview.

Right, and with the addition of preview it was decided that every user will always have preview enabled and the first result is the best result and therefore will be selected.

It is unclear to me what the problem is.

Is “undesired behavior” not a problem? It makes assumptions about what I want and how I work. It should be a preference, like “auto-open first unread email” in mail clients, but the behavior was instead dictated by fiat.

And this is ignoring the “oversight” where the preview window takes up most of the screen width and has to be resized every time (n.b. the monitor I use for coding is in portrait mode because I want to see more lines of code, not wide lines of code…my non-coding monitor is in landscape mode). Yes, the oversight has been (will be?) addressed but that doesn’t make the change to the behavior of a key feature desirable, merely tolerable.

I think we should let the search/replace window also select the first item if the results are known immediately (no async search triggered). This would fill the preview and often result in one click/keystroke less.

“Often” assumes the first result is the best result or that the user is going to step through each result starting with the first and neither scenario seems likely. If there are at most 2 results then auto-selecting the first hit has a reasonable chance of saving a click but not beyond that.

Usage search results aren’t like the results from a search engine where the top hit is determined by a relevancy score. Usage results are ordered alphabetically so the top hit is no more likely to be what I’m looking for than any other result.

Is there a reason the behavior isn’t controlled by a preference or environment variable or was it just that it didn’t seem necessary?

[mbien]

It is unclear to me what the problem is.

Is “undesired behavior” not a problem?

You still haven't mentioned why automatically selecting an item is a problem for you. It doesn't make any qualitative judgement over the first item. If this would be a list and not a tree, it would select the first item by default too. The fact that it is a tree allows it to choose anything between root and a leaf node.

I do also think first leaf node is a sensible default and should frankly be also implemented for search/replace at some point.

NB 23:

NB 24:

NB 23 and 24 async search (many results):

[mbien]

I do also think first leaf node is a sensible default and should frankly be also implemented for search/replace at some point.

I suppose it is sensible for your trivial sample project so we’ll just agree to disagree.

although somewhat amusing, your reply would have made more sense if the last screenshot would not have shown a result with 2130 hits which ran over the OpenJDK code base.

[pgifford]

My comment was intended to bring the topic to a no-hard-feelings conclusion so I apologize for any offense given; it certainly wasn’t intended to be mean.

although somewhat amusing, your reply would have made more sense if the last screenshot would not have shown a result with 2130 hits which ran over the OpenJDK code base.

…in which the first hit wasn’t automatically selected so yay! 😁

✌️

[mbien]

fwiw I don't know who collapsed your reply, but I am going to one up that someone and lock the thread since I don't think there will be an answer to the question why selecting a leaf is worse than selecting the root of the tree.

…in which the first hit wasn’t automatically selected so yay!

exactly, if it would, that would actually be a bug. The selection changes when the scan is done and the user might be already looking through the results at this point.

[neilcsmith-net]

fwiw I don't know who collapsed your reply, but I am going to one up that someone and lock the thread

I did, although I should have just locked it, so thanks!

It was primarily prompted by the thread at https://lists.apache.org/thread/wrodh9d06lhdbch6mmjws0jp33pn6prs When our rare and valuable volunteer contributors feel like apologizing for their contributions, I see a problem! Anyone who feels that this feature is not currently meeting their needs and requires further adaption or customization is more than welcome to work on it. 😄