Bug 447798 - Open Type dialog supports to paste filenames and stacktraces.
Summary: Open Type dialog supports to paste filenames and stacktraces.
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.4.1   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 4.22 M3   Edit
Assignee: Jörg Kubitz CLA
QA Contact: Jörg Kubitz CLA
URL:
Whiteboard:
Keywords: noteworthy, usability
: 457966 484273 501130 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-10-18 23:53 EDT by Robin Stocker CLA
Modified: 2021-11-16 07:19 EST (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Stocker CLA 2014-10-18 23:53:31 EDT
When using Open Type, and pasting a Java file name from somewhere else, e.g. "ArrayList.java", it shows no matches. It would be helpful if the dialog did what I mean and showed matches for "ArrayList" instead.

(One of the small things I've come to appreciate from IntelliJ IDEA. All these small things add up and make a difference in daily use.)
Comment 1 Dani Megert CLA 2014-10-20 08:03:57 EDT
We don't want to add such guesswork to the dialog. If you have something in your clipboard I suggest you use
Navigate > Open from Clipboard
which does all kinds of guessing for you, e.g. it opens the correct element when you have this in your clipboard:
java.lang.Boolean.booleanValue()
Boolean.booleanValue()
Boolean#booleanValue
booleanValue()
booleanValue

It also takes values/lines from a stack trace (or the entire stack trace) as input.
Comment 2 Robin Stocker CLA 2014-10-20 08:42:40 EDT
(In reply to Dani Megert from comment #1)
> We don't want to add such guesswork to the dialog.

You rather show the user 0 results?

> If you have something in
> your clipboard I suggest you use
> Navigate > Open from Clipboard

That doesn't have a keyboard shortcut. And for this one case I should start using a different command than the usual means to open types? 1 point to IntelliJ.

> which does all kinds of guessing for you, e.g. it opens the correct element
> when you have this in your clipboard:
> java.lang.Boolean.booleanValue()
> Boolean.booleanValue()
> Boolean#booleanValue
> booleanValue()
> booleanValue
> 
> It also takes values/lines from a stack trace (or the entire stack trace) as
> input.

That's pretty nice. That fact that I don't know about it doesn't make me confident that it's used by many people at all, sadly.
Comment 3 Noopur Gupta CLA 2015-01-21 00:58:10 EST
*** Bug 457966 has been marked as a duplicate of this bug. ***
Comment 4 Patrick Julian CLA 2015-01-22 07:45:20 EST
(In reply to Dani Megert from comment #1)
> We don't want to add such guesswork to the dialog. If you have something in
> your clipboard I suggest you use
> Navigate > Open from Clipboard
> which does all kinds of guessing for you, e.g. it opens the correct element
> when you have this in your clipboard:
> java.lang.Boolean.booleanValue()
> Boolean.booleanValue()
> Boolean#booleanValue
> booleanValue()
> booleanValue
> 
> It also takes values/lines from a stack trace (or the entire stack trace) as
> input.


Hi Dani,

I fully understand your point to keep the dialog free of guesswork.
For this specific case I don't think it's about guesswork, though:
As ".java" cannot be a part of a type name, and the file names are coupled with the class names, this is something else than the kind of guesswork that e.g. search engines do with a search term.
After all, the dialog is designed to help developers. What's the downside? As I wrote in #457966, this kind of evaluation can be executed after the regular search process. Then performance doesn't suffer.

Therefore I'd like to second Robin regarding his opinion, as I suspect that the "pro" arguments have not yet been fully considered.

Cheers
Patrick
Comment 5 Noopur Gupta CLA 2015-12-12 14:35:57 EST
*** Bug 484273 has been marked as a duplicate of this bug. ***
Comment 6 Phillip Webb CLA 2015-12-12 15:25:13 EST
Just like to add my +1 for this issue.

As part of my regular workflow I often want to jump between some patch that I'm reviewing with `git diff` and the file within the IDE.

Given git output like this:

diff --git a/spring-boot-actuator/src/main/java/org/springframework/boot/actuate/autoconfigure/EndpointWebMvcChildContextConfiguration.java b/spring-boot-actuator/src/main/java/org/springframework/boot/actuate/autoconfigure/EndpointWebMvcChildContextConfiguration.java
index 70d9d18..8059296 100644
--- a/spring-boot-actuator/src/main/java/org/springframework/boot/actuate/autoconfigure/EndpointWebMvcChildContextConfiguration.java
+++ b/spring-boot-actuator/src/main/java/org/springframework/boot/actuate/autoconfigure/EndpointWebMvcChildContextConfiguration.java
@@ -67,6 +67,7 @@ import org.springframework.web.servlet.config.annotation.EnableWebMvc;

I usually just double click on the filename, jump to Eclipse, hit cmd-shift-t and paste. On OSX at least, double-clicking always include the `.java` suffix so I always need to delete this in the open type dialog.
Comment 7 Dani Megert CLA 2015-12-17 09:45:20 EST
(In reply to Phillip Webb from comment #6)
> I usually just double click on the filename, jump to Eclipse, hit
> cmd-shift-t and paste. On OSX at least, double-clicking always include the
> `.java` suffix so I always need to delete this in the open type dialog.

See comment 1 to do this even faster.
Comment 8 Phillip Webb CLA 2015-12-17 10:18:37 EST
@DaniMegert : Fantastic! Thanks, I totally missed that comment. It would be nice to have a default keyboard shortcut for that, it's super useful.
Comment 9 Patrick Julian CLA 2015-12-17 10:30:45 EST
@ Phillip Webb: Yes, it's a great feature, but as you can see from your own case, it only helps you when you know that it exists. "Open Type" will not help you. That is sad.

I would much therefore highly appreciate if the idea to improve the "open type" results is reconsidered. After all, it is there to give you quick access. It should be an (even more) helpful assistant.
Comment 10 Dani Megert CLA 2015-12-17 11:09:47 EST
(In reply to Phillip Webb from comment #8)
> @DaniMegert : Fantastic! Thanks, I totally missed that comment. It would be
> nice to have a default keyboard shortcut for that, it's super useful.

If we'd only had some free ones :-)
Comment 11 Noopur Gupta CLA 2016-09-09 08:08:20 EDT
*** Bug 501130 has been marked as a duplicate of this bug. ***
Comment 12 Frank Musolf CLA 2017-02-01 02:55:47 EST
+1 for accept .java
+1 for key action for open from clipboard
Comment 13 Dani Megert CLA 2017-04-14 05:35:54 EDT
(In reply to Frank Musolf from comment #12)
> +1 for key action for open from clipboard

It's there since Neon (4.6), see bug 487575 for details.
Comment 14 Mickael Istria CLA 2019-04-01 04:40:17 EDT
I'd like to reopen this one.
I think it's not so difficult and it'd be a nice to have, and the fact that there are other decent workflows for this story shouldn't prevent this one from being improved/made possible too is some users would like to use it.
Comment 15 Dani Megert CLA 2019-04-01 09:19:46 EDT
Sorry, but I am strictly against this. Foo.java is not a type and the dialog is there to open types.

How about solving the problem differently? We could remove ".java" and ".class" from the pasted string before inserting it.
Comment 16 Mickael Istria CLA 2019-04-01 10:42:14 EDT
(In reply to Dani Megert from comment #15)
> How about solving the problem differently? We could remove ".java" and
> ".class" from the pasted string before inserting it.

+1
Comment 17 Eclipse Genie CLA 2021-03-20 19:28:49 EDT
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/178149
Comment 18 Eclipse Genie CLA 2021-10-14 14:34:46 EDT
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/186496
Comment 19 Jörg Kubitz CLA 2021-10-18 08:01:40 EDT
If a string is pasted into the Open Type dialog it is automatically
cleaned up to the included type name by best effort.

Paste will strip filenames like:

1) /dev/src/p/MyType.java -> MyType
2) c:\dev\src\p\MyType.java -> MyType

This works because slash and backslash cannot be part of type name and assuming "java" (all lower case) is never used as a typename (uppercase convention)

Convert stacktraces from various source like
3) at mypackage.MyType.main(Test.java:58) -> mypackage.MyType

This works because parentheses cannot be part of type name but follow on a unneeded method name, and assuming "at " introduces a stacktrace line by convention.

Strip Lambdas like
4) o.e.u.i.Workbench$$Lambda$152/0x00000001002a1928.run(Unknown Source) -> o.e.u.i.Workbench

by assuming "$$Lambda" is not used in regular type names.

This approach would also be possible for, but DOES NOT implement:
a) .class files like MyType.class -> MyType
b) binary names of inner types like java.util.Map$Entry->java.util.Map.Entry

If further conversions are wanted please comment with a reasoning.
Comment 20 Andrey Loskutov CLA 2021-10-19 02:03:00 EDT
(In reply to Jörg Kubitz from comment #19)
> This approach would also be possible for, but DOES NOT implement:
> a) .class files like MyType.class -> MyType
> b) binary names of inner types like java.util.Map$Entry->java.util.Map.Entry
> 
> If further conversions are wanted please comment with a reasoning.

The two items above would also make sense.
Comment 21 Jörg Kubitz CLA 2021-10-20 08:40:03 EDT
(In reply to Andrey Loskutov from comment #20)
> The two items above would also make sense.

Since two committers asked for it i assume its useful -> implemented.
Comment 23 Noopur Gupta CLA 2021-11-08 08:09:30 EST
Thanks, Jörg.
Comment 24 Lars Vogel CLA 2021-11-08 08:55:08 EST
Please add to N&N
Comment 25 Eclipse Genie CLA 2021-11-08 09:21:05 EST
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/187509