Community
Participate
Working Groups
20030214 1. Open a plugin.xml in the Plugin Manifest editor, open the source page 2. Add a whitespace somewhere, scroll to the end of the document 3. Press 'Go to last edit position' in the toolbar Nothing happens
As a meta-comment, we are not going to provide the level of source editing support you are used to in Java editor, so you can open defects like this one but the probability of them being addressed is low.
Dejan, ctrl-Q is the one and only keybinding left that does not work in the new editor. It is available in the plain text editor, so we are losing it at some point during the integration of editors. Once it's in, we could officially declare success and we would make Martin happy (for now :-)
This is going to be very hard. The action is properly hooked and executes, but the problem is in the 'run' method: IEditorPart editor; try { editor= page.openEditor(editPosition.getEditorInput(), editPosition.getEditorId()); } catch (PartInitException ex) { editor= null; } // Optimization - could also use else branch if (editor instanceof ITextEditor) { ITextEditor textEditor= (ITextEditor)editor; textEditor.selectAndReveal(pos.offset, pos.length); } In the code above, the actions tries to open the editor for the edit position input. This does not take into account if the returned editor is MultiPageEditorPart. Obviously, the returned editor does not implement ITextEditor and the 'instanceof' check fails. As I said, this is a hard problem. Somewhere between platform UI and text team, there has to be a check if the returned editor is MultiPageEditorPart. If so, the nested editor with the matching editor input should be located and it should be the target of the 'selectReveal' call. Adding Kai for comments.
An alternative way of addressing this would be to make the text editor implement the new interface 'ISelectRevealTarget': interface ISelectRevealTarget { void selectAndReveal(IEditorInput input, int offset, int length); } AbstractTextEditor can implement this method by simply calling existing 'selectAndReveal(int, int)'. The implementation of GotoLastEditPositionAction can test if the editor is ISelectRevealTarget instead of ITextEditor. If true, call the method above. Our editors will implement the method, locate the nested source page that matches the provided editor input, and call 'selectAndReveal' on the text editor in that page. Can we do this?
*** Bug 80108 has been marked as a duplicate of this bug. ***
We now send a text selection and hence Goto Last Edit Position works fine for multi-page editors who handle selection changed events and who only have one source file. The problem with the PDE editor is that he might have several source pages. The final solution is probably something like the suggested ISelectRevealTarget. Could you propose that new API to Platform UI? Currently the PDE Editor does nothing if the current page isn't a source page. Could the PDE editor switch to the source page if there's only one?
cc Nick for a Platform/UI perspective.
I was also going to suggest using TextSelection textSel = ...; editor.getSite().getSelectionProvider().setSelection(textSel); (with the appropriate null checks added) But as Dani says, this doesn't handle the case where there are multiple files involved. I'd be OK adding something like: public interface IEditorSelectRevealTarget { /** * Selects and reveals the given selection in the editor implementing * this interface. The editor input is also passed to disambiguate * the case where the editor handles multiple inputs. * * @param input the editor input * @param selection the selection to show * @return true if the selection could be shown, false otherwise */ boolean selectAndReveal(IEditorInput input, ISelection selection); } We could also use this to improve editor linking in the Navigator, Package Explorer and similar views. It would be nice to generalize this to views too, but views don't have the notion of input. Stefan, do you have any suggestions here?
Moving to Platform/UI for API consideration.
Is this still a problem in 3.3? PW
Still an issue in I20060926-0935. The action only works when the PDE manifest editor is still open and shows the right source page. Is a no-op when the editor is closed. Switches to the wrong editor page when another page is visible (e.g. switches to the Extensions page when last edit was in plugin.xml.
investigation. PW
Related information: The action, org.eclipse.ui.edit.text.gotoLastEditPosition, does not allow retargeting, and therefore does not work with non-text editors. A reasonably simple partial solution would be to change the action to allow retargeting, and create a command handler that is active when the activeEditor is an instanceof AbstractTextEditor. While not perfect, this would be a significant improvement on the current arrangement. This would allow other editors to define their own command handlers for when they are active. Longer-term the set/get LastEditPosition should sit in a plugin other than TextEditorPlugin, and should be generic, allowing for different methods of specifying the last item edited. Currently it supports spans of text, but it should support any means of location (such as an ISelection). (See Bug 299445)
This got worse in 4.x, see bug 392414.
It is the general issue involved with the multi page editors. In short it works in this way: The new e4 version of the WorkbenchPage.busyOpenEditor method takes empty editor id and throws PartInitException. As the result of the exception the GotoLastEditPositionAction action does nothing. The empty id is returned by the MultiPageEditorSite.getId method and put to the WorkbenchPage.busyOpenEditor one generally via the EditPosition object I'm working on fix for that, Daniel
(In reply to comment #15) > It is the general issue involved with the multi page editors. In short it > works in this way: > > The new e4 version of the WorkbenchPage.busyOpenEditor method takes empty > editor id and throws PartInitException. As the result of the exception the > GotoLastEditPositionAction action does nothing. This has been fixed for 4.4 M1 (see bug 413430).
(In reply to comment #11) > Is a no-op > when the editor is closed. This got better with the fix for bug 413430, but it still does not select the correct page.
Created attachment 234094 [details] Screenshot
(In reply to comment #18) > Created attachment 234094 [details] > Screenshot While testing the fix for bug 413430, found that the text message can be improved in the following case: a) Edit plugin.xml in Plug-in Manifest editor and save. b) Close the plug-in project. (Right-click > Close Project) c) Press Ctrl+Q. The message on the editor is attached as screenshot and can be improved grammatically.
(In reply to comment #19) > (In reply to comment #18) > > Created attachment 234094 [details] > > Screenshot > > While testing the fix for bug 413430, found that the text message can be > improved in the following case: > a) Edit plugin.xml in Plug-in Manifest editor and save. > b) Close the plug-in project. (Right-click > Close Project) > c) Press Ctrl+Q. The message on the editor is attached as screenshot and can > be improved grammatically. Noopur, this comment does not belong into this bug. The message comes from PDE and it is correct: the file is not available. If you think it can be improved, then please open a bug against PDE UI with a proposal to improve it. Please cc-me if you do so. Thanks.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
