Community
Participate
Working Groups
Build Identifier: Build id: 20110916-0149 When you use code completion for a method, and are filling in the arguments for that method, javadoc view should be displaying the javadoc for the method you are working on. More Details here: http://www.youtube.com/watch?v=gWKfFLLGbTQ Also it would be nice if the javadoc for a type listed the methods/fields that type had. note: we need this for our teaching kids java program, and I would be happy to pair program to fix it. Reproducible: Always Steps to Reproduce: 1.type String.copyValueOf 2. look at the javadoc view 3. notice the documentation is only for the string type
*** Bug 387078 has been marked as a duplicate of this bug. ***
Adding information from 387078: https://bugs.eclipse.org/bugs/show_bug.cgi?id=387078 Often when looking at method calls with many parameters, I'd need to know what a particular parameter's purpose is by reading its Javadoc. Presently I have to count the number of parameters until I reach the one of interest, then I have to hover over the method name and count again. I should be able to bring up the Javadoc of the individual parameter (or the parameter in the Javadoc should at least be highlighted/bolded as it is in IntelliJ with control-P). I should be able to bind it to a hotkey or possibly just by hovering over the parameter (this would likely require a mouse modifier.) Further clarification: Suppose I have the following code: void foo(int i) {} void bar() { foo(1); } If I hover over the 1, I would like to see "int i" as I do if I hover over "foo". I know this can conflict with showing the Javadocs of methods or fields in the parameter such as how presently Eclipse shows on hover the Javadoc for random() below: void bar() { foo(random()); }
Created attachment 221799 [details] mylyn/context/zip I am interested in working on a fix for this. So far it looks non-trivial. The reason it works for class completion and not method completion is that what the Javadoc view shows is entirely based on selection. When you complete a constant, it puts the selection at the end of the constant, which is a valid way to select an element. However, when you complete a method, the cursor is put between the brackets selecting the parameters if there are any. This is not a valid selection of the method so it does not show up in the Javadoc view. I see two ways of fixing this: 1. Fix the Javadoc view to take autocompletion into account. 2. Fix the selection to Java element mechanism so that if the cursor is between the brackets of a method call and any selected parameters do not connect to an element, the method is returned. This would also fix the problems listed in bug #387078 but it would be harder to implement.
I think we should fix bug 70631 and then use the "Edit > Content Assist > Parameter Hints" infrastructure to find an alternative input for the Javadoc view. Code pointer: JavaCompletionProposalComputer#guessMethodContextInformationPosition(..)
(In reply to comment #4) > I think we should fix bug 70631 and then use the "Edit > Content Assist > > Parameter Hints" infrastructure to find an alternative input for the Javadoc > view. > > Code pointer: > JavaCompletionProposalComputer#guessMethodContextInformationPosition(..) That's a good idea. I'll take a look at bug 70631 before doing anything more on this.
*** Bug 233528 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Created attachment 221799 [details] > mylyn/context/zip > > I am interested in working on a fix for this. So far it looks non-trivial. > > The reason it works for class completion and not method completion is that > what the Javadoc view shows is entirely based on selection. When you > complete a constant, it puts the selection at the end of the constant, which > is a valid way to select an element. However, when you complete a method, > the cursor is put between the brackets selecting the parameters if there are > any. This is not a valid selection of the method so it does not show up in > the Javadoc view. > > I see two ways of fixing this: > 1. Fix the Javadoc view to take autocompletion into account. > 2. Fix the selection to Java element mechanism so that if the cursor is > between the brackets of a method call and any selected parameters do not > connect to an element, the method is returned. This would also fix the > problems listed in bug #387078 but it would be harder to implement. While I have not looked at the code (although I repeat my offer to pair program with someone) I would suggest a 3rd fix. javadoc stays on the last object that was useful. therefor you could open a manual event javadoc.show( method ) and then it would display until you clicked somewhere that changed it. This should be fairly easy (again not having looked at the code :-)
That's basically what I was thinking for my suggestion of directly integrating with autocomplete. Manually show the javadoc in the autocomplete method and then leave it there. I think fixing bug 70631 and then integrating that code into the javadoc view might be better. It is harder but it fixes 3 bugs: this one, #70631 and the problems specified in the (now merged) #387078. However, one pitfall I can think of is that say you have a class with a Javadoc'd property named 'number'. Then you complete a method named String.valueOf(number), if the Javadoc is purely selection based and it only shows the method documentation if the parameter has none, it will show the documentation for 'number' instead of the method.This is the desired behaviour for selecting number normally but not the desired behaviour for autocompletion. Also making it keep the last useful documentation would possibly be a desired behaviour anyway. Right now if I select something and then click something with no Javadoc, it will change to showing nothing. I am not a UX person but I think it might be better if it stayed. Also it would fix the minor performance bug that every time you move the cursor, it sets the html of the javadoc view to the same blank page. I haven't done any profiling but I imagine it has some impact since it's constantly parsing and rendering. Could a commiter maybe weigh in on this? Markus?
(In reply to comment #8) Sounds mostly good. I agree that the last useful documentation should be kept if there's no resolvable element at the selection. I.e. it should behave like Mark Occurrences with the "Keep marks when the selection changes" preference enabled. As soon as a new element is resolvable, that one should be used. The "String.valueOf(number)" with "number" selected should use "number" as input for the Javadoc view. I know this is not perfect for the Content Assist scenario, but it is predictable, and the user can move the caret away from a resolvable element to get the enclosing method invocation's Javadoc. If we later find that this is really not working well, then we could consider an additional mode where the enclosing method invocation has preference as long as the linked mode from Content Assist is active (e.g. in the case where Content Assist inserted "valueOf(number)" and shows the argument proposal popup). Re not updating when the caret moves: We have to be careful to make sure we don't lose updates. E.g. when the user types a character in a Javadoc comment, then we need to update.
Created attachment 221917 [details] Patch to keep the last thing selected in the Javadoc view. Does not fix the bug. I fixed the Javadoc view to display the last thing selected when it would normally change the view to a blank page. This doesn't actually fix this bug but it is a step forward. Should I create a new bug for keeping the last displayed documentation and then immediately submit a patch for it?
(In reply to comment #10) Thanks for looking into this. The change for bug 344552 broke the "keep last input" feature (only partially, the input still stayed when you e.g. selected something in the Outline and then cleared the selection). I've replaced that fix with a better fix that simplifies the code and that only clears the AbstractInfoViews when the last input element doesn't exist any more: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=3e2abb76301eefadbd08833e6980d0d2545b0654
Sorry, I forgot to push. Here's the commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=7f05b409eeef9e2707566c837bc1f3b77e8d1a45
Created attachment 222080 [details] Patch to search for enclosing method calls when selecting something that is not a Java element. Here is a fix I wrote that uses similar techniques to JavaCompletionProposalComputer#guessMethodContextInformationPosition to find the method from a selection inside the parameters list. When codeSelect fails it tries searching for an enclosing method call and then recursively runs findSelectedJavaElement on that. It also works on constructors for parameterized types. For example, a selection in the parameter list of "new ArrayList<String>(234)" will show the documentation for ArrayList.
(In reply to comment #12) > Sorry, I forgot to push. Here's the commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/ > ?id=7f05b409eeef9e2707566c837bc1f3b77e8d1a45 Markus, does this commit contain any of Tristan's patch?
Comment on attachment 221917 [details] Patch to keep the last thing selected in the Javadoc view. Does not fix the bug. (In reply to comment #14) No, my commit doesn't contain anything from the patch in comment 10. The final fix will most probably contain comment 13, so I'll set Tristan as author when I'll commit that.
(In reply to comment #13) > Created attachment 222080 [details] [diff] > Patch to search for enclosing method calls when selecting something that is > not a Java element. Thanks, the patch looked good. Released as http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=e8b82f77658c651270cf249d1d067122a60941bb
THANKS! Downloaded it today, and it works great. I hate to be nit picky, because this is really really good, but the behavior is inconscient with empty parameters. in other words: "hello".charAt(3); will bring up the documentation for charAt(int) but "hello".toCharArray(); will bring not bring up the documentation for toCharArray() If you can make it conscient it would be good. But I'm super happy with it right now, it' a huge bonus when teaching kids to thanks!
As a 16 year old who learned to program as a kid I can see how it would be helpful. The no parameters thing might be a bug in my patch I'll have a look at it.
Created attachment 223007 [details] Fix for comment 17 > but > "hello".toCharArray(); > will bring not bring up the documentation for toCharArray() It works for me as long as the caret is on the left of the closing ')'. The problem is that content assist inserts "toCharArray()" and places the caret to the right of the closing ')' if the method doesn't have arguments. I think we have to account for this case; otherwise the feature looks unpredictable. Note that we have a conflict in situations like this: equals("hello".toCharArray()|); The patch gives priority to the enclosing method invocation and only falls back to the special case for the ')' if no method could be found otherwise. Dani, OK to put this into M3?
(In reply to comment #19) > Created attachment 223007 [details] [diff] > Fix for comment 17 > > > but > > "hello".toCharArray(); > > will bring not bring up the documentation for toCharArray() > > It works for me as long as the caret is on the left of the closing ')'. The > problem is that content assist inserts "toCharArray()" and places the caret > to the right of the closing ')' if the method doesn't have arguments. > > I think we have to account for this case; otherwise the feature looks > unpredictable. Note that we have a conflict in situations like this: > equals("hello".toCharArray()|); > > The patch gives priority to the enclosing method invocation and only falls > back to the special case for the ')' if no method could be found otherwise. > > Dani, OK to put this into M3? +1
(In reply to comment #19) Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=09ed6f87a493fd32d5eff0cf1ae4182f76d5d780
Verified in 4.3 M3.
