This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[ BUILD # : trunk ] [ JDK VERSION : 1.7 ] Java/C code snippet: void foo(...) {...} After marking 'void', "Find Usages" should search for uses of keyword 'void' instead of name 'foo'.
Thank you for the report. Do you have a use case which shows it would be more useful to have Find Usages work on keywords than using Find in Projects? Adding support for finding keyword usage would not be faster than Find in Projects, but makes the selection more strict, which I think would negatively influence the usability of Find Usages.
(In reply to comment #1) > Thank you for the report. Do you have a use case which shows it would be more > useful to have Find Usages work on keywords than using Find in Projects? See below... > Adding support for finding keyword usage would not be faster than Find in > Projects, but makes the selection more strict, Correct! There is a principal logical difference between both. Find in Projects is a semantics free text pattern search, but not Find Usages, it depends on the semantic of the search string in the particular language e.g. Java, C, PHP, HTML etc. Find in Projects with "public" will find e.g.: - "public" as keyword, name or comment - "publicity" as name or comment - "PUBLIC" e.g. as constant name - "java.security.PublicKey" interface depending on the current settings in Find dialogue. In addition to this free text search user wants to select an item in the program language context and just quickly search for it's pure uses, without adjusting options like "Match Case", "Whole Words" etc. If the user selects "void" from comment 0, opens context-menu and erroneously invokes "Find Usages" he (1) has to start again and (2) additionally doesn't find "Find in Projects" in the context menu, so (3) has to think about how to invoke it, and (4) in 99 % he doesn't want to find uses of "foo". > which I think would negatively influence the usability of Find Usages. Can you explain more detailed what this could be?
Additionally on e.g. marking the 'L' from 123L or '"' from "Hello", "Find Usages" could search for literals of long or String type. Maybe there are more sophisticated suggestions, e.g. search for casts.
(In reply to comment #2) > (In reply to comment #1) > > Thank you for the report. Do you have a use case which shows it would be more > > useful to have Find Usages work on keywords than using Find in Projects? > > See below... I apparently did not ask this clearly enough. Personally I do not see the need of the possibility to find all occurrences of a java keyword. I think in any real-world project the number of occurrences would be too high to be of any use. Could you give me an example where a user wants to find all occurrences of a java keyword that would help him in his every day job? > > Adding support for finding keyword usage would not be faster than Find in > > Projects, but makes the selection more strict, > > <snip> > > In addition to this free text search user wants to select an item in the > program language context and just quickly search for it's pure uses, without > adjusting options like "Match Case", "Whole Words" etc. > If the user selects "void" from comment 0, opens context-menu and erroneously > invokes "Find Usages" he (1) has to start again and (2) additionally doesn't > find "Find in Projects" in the context menu, so (3) has to think about how to > invoke it, and (4) in 99 % he doesn't want to find uses of "foo". > > > which I think would negatively influence the usability of Find Usages. > Can you explain more detailed what this could be? Selecting code elements by selecting characters in an editor can be surprisingly difficult for programmers[1]. Making this selection more strict would not help. (4) I would like to challenge this statement. I think the majority of users do want to invoke Find Usages on foo(). Do you have any data backing this up? [1] Breaking the Barriers to Successful Refactoring: Observations and Tools for Extract Method. Emerson Murphy-Hill and Andrew P. Black. International Conference on Software Engineering. 2008.
(In reply to comment #4) > I apparently did not ask this clearly enough. Personally I do not see the need > of the possibility to find all occurrences of a java keyword. I think in any > real-world project the number of occurrences would be too high to be of any > use. Could you give me an example where a user wants to find all occurrences of > a java keyword that would help him in his every day job? (1) If I have an abstract Java class, I want to find the abstract methods quickly. (2) If I want to list all byte type variables in a class to examine, if I could change them to int type variables. (3) If I want to find all nested classes in a class. (4) Finding the uses of a particular annotation. In all these examples, I don't agree to "the number of occurrences would be too high". > (4) I would like to challenge this statement. I think the majority of users do > want to invoke Find Usages on foo(). Do you have any data backing this up? If a user wants to find the uses of foo(), why should he mark 'void' rather than 'foo'? BTW: the term "Usages" is wrong in this context, see: bug 152130
(In reply to comment #5) > (In reply to comment #4) > > I apparently did not ask this clearly enough. Personally I do not see the need > > of the possibility to find all occurrences of a java keyword. I think in any > > real-world project the number of occurrences would be too high to be of any > > use. Could you give me an example where a user wants to find all occurrences of > > a java keyword that would help him in his every day job? > > (1) If I have an abstract Java class, I want to find the abstract methods > quickly. Sounds like a useful feature, but I think this should be supported by the navigator. Don't you? > (2) If I want to list all byte type variables in a class to examine, if I could > change them to int type variables. I agree that Find Usages on primitive types would be an useful enhancement. > (3) If I want to find all nested classes in a class. This is already available in the navigator. > (4) Finding the uses of a particular annotation. Already supported. > In all these examples, I don't agree to "the number of occurrences would be too > high". > > > (4) I would like to challenge this statement. I think the majority of users do > > want to invoke Find Usages on foo(). Do you have any data backing this up? > > If a user wants to find the uses of foo(), why should he mark 'void' rather > than 'foo'? Because void is part of the method declaration you can invoke Find Usages on.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > I apparently did not ask this clearly enough. Personally I do not see the need > > > of the possibility to find all occurrences of a java keyword. I think in any > > > real-world project the number of occurrences would be too high to be of any > > > use. Could you give me an example where a user wants to find all occurrences of > > > a java keyword that would help him in his every day job? > > > > (1) If I have an abstract Java class, I want to find the abstract methods > > quickly. > > Sounds like a useful feature, but I think this should be supported by the > navigator. Don't you? Is that inside one file? I would say that Find Selection (Ctrl-F3 - may have different shortcut on Mac) already does that and does that better (no mess with dialog, etc.). > > > (2) If I want to list all byte type variables in a class to examine, if I could > > change them to int type variables. > > I agree that Find Usages on primitive types would be an useful enhancement. Hm, possibly. Inside one file can be done with Find Selection again, and across many files can already be done by using custom rule in Source/Inspect. Not as quick as finding all occurrences of word "byte", but allows to look only for variables (or specifically fields/local variables) - no clutter with e.g. methods with return type byte. > > > (3) If I want to find all nested classes in a class. > > This is already available in the navigator. Or, in one file, Find Selection of keyword "class" again (which, again, I find easier than FU on "class"). But I find navigator for that better as well.
(In reply to comment #6) > > (1) If I have an abstract Java class, I want to find the abstract methods > > quickly. > > Sounds like a useful feature, but I think this should be supported by the > navigator. Don't you? But it doesn't :-( > > (3) If I want to find all nested classes in a class. > > This is already available in the navigator. Navigator can have a looong list. Scrolling through it could be awful. FU would present you a well-arranged list, highlighting the occurrences in it's line context. > > If a user wants to find the uses of foo(), why should he mark 'void' rather > > than 'foo'? > > Because void is part of the method declaration you can invoke Find Usages on. Why should the user mark 'void' for finding uses of 'foo'? Well, I've given 4 examples here, but I can imagine 10s of others. I often missed the possibility to distinctly search for the uses of a particular keyword. (In reply to comment #7) > > > (1) If I have an abstract Java class, I want to find the abstract methods > > > quickly. > > > > Sounds like a useful feature, but I think this should be supported by the > > navigator. Don't you? > > Is that inside one file? I would say that Find Selection (Ctrl-F3 - may have > different shortcut on Mac) already does that and does that Ctrl-F3 supplementary would find all occurrences in javadoc > better (no mess with dialog, etc.). I would say contrary. User first has to adjust the options like "Match Case", "Whole Words" etc. in the Find dialogue, and additionally he won't get the nice list in the output window. > > I agree that Find Usages on primitive types would be an useful enhancement. > > Hm, possibly. Inside one file can be done with Find Selection again, If option are set accordingly, but user additionally will find all occurrences in comments. > Not as quick as ... Yes, that's the point. > Or, in one file, Find Selection of keyword "class" again (which, again, I find > easier than FU on "class"). But I find navigator for that better as well. See above.