Summary: | Feature: navigate from console output to resource (1G81S73) | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Erich Gamma <erich_gamma> |
Component: | Debug | Assignee: | Darin Wright <darin.eclipse> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | enhancement | ||
Priority: | P1 | CC: | eclipse |
Version: | 2.0 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | Windows NT | ||
Whiteboard: |
Description
Erich Gamma
2001-10-10 22:14:54 EDT
Have experimented with both approaches outlined, and decided using the java SearchEngine is prefereable to hunting for resources. Within this choice there are several options on how to use the SearchEngine. Decided to use the 'searchAllTypeNames()' method, as this had somewhat better performance than the others. Implemented. If there is an explicit selection in the console, this is parsed for a package, type and line number. If no selection, the entire line in the console where the cursor is located is parsed. In either case, the package name and line number are optional, the type name is required. In ambiguous situations (e.g., "List" is selected), a selection dialog is opened. Verified that open on type works in positive cases. Problem I noticed is that if the selection cannot be resolved to a type, then nothing happens, and there is no warning/message. Options are to pop up a dialog, or open an "open on type" dialog (a la toolbar), with an initial selection of whatever was selected. For example, I selected "main" in the conosle and did an open on type and nothing happenned. Instead, could open the "open on type" dialog, and populate the text field with "main". Thoughts? My thought was that the normal use of this action was with NO selection. I.e., simply place the cursor on a line of output in the console and then choose 'Open on Type' from the context menu. The action will parse the entire line and in the case of a standard Java walkback (and a few other cases), it will 'do the right thing' and open an editor on the referenced type. I only included an option to look at explicit selections because it seemed somewhat useful in the case where a programmer outputs a class name as a debugging aid, and then decides to open that class. 99% of the time, I think such a selection will be done as a double-click, which should select the type correctly, if there are separators around the name. I do see the potential for confusion though and will investigate the suggested fix. After thinking about it a bit, I'm not sure that bringing up a dialog in the case that no type can be resolved for the 'open on type' action is a good idea. There are two cases: (1) An explicit selection was made, but it was a bad selection that didn't actually get the desired type name. The selection probably missed the desired type name by one or two characters on the beginning or end. If it differs on the end, then bringing up a dialog seeded with the selection probably would save the user a few keystrokes, but if it differs on the beginning, then using the selection as a seed for the dialog is actually not at all what the user wants, and will cause them to have backspace out the initial value, or start over. (2) There is no explicit selection, so the action attempts to parse the entire line. If it cannot parse a valid type out of the line, then the line is not part of a standard Java walkback, in which case we have no idea what it is. In this case, seeding the dialog with the entire line would probably result in nonsense. In general, we could avoid seeding the dialog, but then this is just the same as invoking the standard toolbar action to open a type. I can see that there might be some benefit in having the action try its best to parse a type name and open it, but in case of failure default to asking the user to choose a type from ALL of the types in the workspace. But, is this desireable behavior? Will leave action as is for now. Fixed. Verified. |