Community
Participate
Working Groups
Because patches are line-number based, it would really help if you could tell what line number you were looking at in the compare patch browser. If the patch can't be lined up properly, the natural thing is to assume that the line numbers have changed significantly, and so the first thing you try to do is "Find" the .reg file strings in the left (workspace) pane, and figure out what line number the patch should really be referring to. (I usually use Goto Line... in any text editor to determine what line I am on). The problem is that the patch compare browser does not have Find... or Goto Line...
Moving to Compare.
*** Bug 2057 has been marked as a duplicate of this bug. ***
Every Compare editor should have Find and Goto Line.
Not for 2.0
What about having this in Eclipse 3.1?
Would be cool! The problem is: we don't want to duplicate gazillion features of the underlying text editors. So we are reluctant to port anything that exists there over to Compare. Instead we are working on making editors (or parts in general) better composable. This would make it possible to compose Compare editors and dialogs/patch dialogs from "real editors" and not from low-level widgets as it is done today.
Find and Line numbers have been added in 3.3 M7. We didn;t add CTRL-L so I'll leave this bug open.
*** Bug 13870 has been marked as a duplicate of this bug. ***
Michael, I need to kindly ask you for some clues on how to ship Goto Line to Compare Editor. First, I added a keybinding for the compare editor scope context. That was the easiest part. Due to the fact that CompareEditor is not an instance of ITextEditor I couldn't simply delegate the call to the GotoLineAction (which was my first idea). The second was to rewrite, at least the crucial part, the GotoLineAction so it can be used in Compare project. What made me totally confused was the fact that I have no idea how to get an IDocument of the CompareEditorInput. The IDocument object is need for obtaining the line numbers of the file and for selecting the given line. And I'm not talking only about the fact that the input is made out of two... resources. The other lead was to figure out how are the line number calculated for the compare editor. This is the connection I found: To make the LineNumberRuler works we need to use a ITextViewer with it. SourceViewer implements ISourceViewer which extends ITextViewer. The MergeSourceViewer class used in CompareEditorInput is a subclass of the SourceViewer class. After discovering that my first thought was that I somehow need to get the MergeSourceViewer object from the CompareEditorInput and then probably I will be able to get the IDocument I've been looking for. I'm sorry if the above doesn't make any sense to you. The amount of code I've seen trying to figure out how to "bite" the bug overwhelmed me :)
Dani, is there any chance in getting the GotoLineAction in Workbench/TextEditor pushed down or should we just write our own? Tomek, the easiest solution would be to add the action in the MergeSoureViewer itself so you would have access to the document. Perhaps you could add it in the MergeSourceViewer#menuaboutToShow method.
>Dani, is there any chance in getting the GotoLineAction in Workbench/TextEditor >pushed down or should we just write our own? Do you mean to provide a GotoLineAction for an ITextViewer? All our actions are targeted towards ITextEditor. There are just some very few exceptions like the FindReplaceAction which can also work on an IFindReplaceTarget. I have no lans to do this for Goto Line. As a workaround you could create an ITextEditor adapter for your source viewer. But that needs some glue code. However, that seems to be too much unless you could use that to exploit other text editor actions. BTW: You might want to look at: org.eclipse.ui.console.actions.TextViewerGotoLineAction
Given that we need to write the action from scratch, we won't have time to get to this in M1.
Postponing to 3.5.
*** Bug 248350 has been marked as a duplicate of this bug. ***
Created attachment 114438 [details] Patch v01 Patch that adds "Go to Line" action to context menu in Compare Editor, the entered line is selected properly despite the fact that it looks like selected lines are decorated differently in TextEditors. The other remaining issue is missing key binding.
Created attachment 114439 [details] mylyn/context/zip
Did you try the >As a workaround you could create an ITextEditor adapter for your source viewer. >But that needs some glue code. approach? Given that we might want to add more editor features this might be better i.e. less copied code.
Created attachment 114533 [details] Patch v02 This is how such adapter could look like. I'm not sure whether implementing ITextEditor is enough here or should I try to use AbstractTextEditor as a base class. Next thing I would like to get rid of are changes in *.properties file. If I could somehow reach EditorMessages and its bundle it would safe us from copy-pasting more code. The patch still has commented out markInNavigationHistory method, so there is no sign of skiping lines in the navigation history. The other thing is that if we have in mind adding more Java features to Compare Editor I guess TextEditorAdapter shouldn't be bounded to a single SourceViewer. Instead the adapter should be available from CompareEditor and it should handle multiple SourceViewers. How does it sound?
(In reply to comment #15) > Created an attachment (id=114438) [details] > Patch v01 > > (...) The other remaining issue is missing key binding. Paul, could you give me a helping hand here?
>I'm not sure whether implementing >ITextEditor is enough here or should I try to use AbstractTextEditor I wouldn't do this. You have better control if you implement those methods that are needed in the context of the compare viewers. >Next thing I would like to get rid of are changes in *.properties file. >If I could somehow reach EditorMessages and its bundle This won't happen. Message bundles are internal. However, what I could do is offer you a GotoLineAction(ITextEditor editor) that has the strings set.
(In reply to comment #20) > >Next thing I would like to get rid of are changes in *.properties file. > >If I could somehow reach EditorMessages and its bundle > This won't happen. Message bundles are internal. However, what I could do is > offer you a GotoLineAction(ITextEditor editor) that has the strings set. This would be great, do you want me to open a bug for it?
>This would be great, do you want me to open a bug for it? I've already done it for you (it's in HEAD).
Created attachment 114680 [details] Patch v03 Updated version of the previous patch, uses the new GotoLineAction constructor provided by Dani.
Created attachment 114934 [details] Patch v04 Finally a working patch! As Paul suggested I activated the Text Editing scope for the Compare Editor to enable Ctrl+L key binding. This works for the Compare Editor only, so I'll open a bug to add Go to Line action for other context as well.
Created attachment 114935 [details] mylyn/context/zip
On second thought, I'm not so sure if activating "Editing Text" for Compare Editor is the best solution. Compare Editor can be opened not only for text comparisons. This fact makes bug 250624 to rise in importance. The fix for it would probably activate the context for TextMergeViewer not CompareEditor
Latest patch released to HEAD, bug logged bug 250624 (see comment above).
