Community
Participate
Working Groups
Restoring Cursor-Positions in Texteditor-Windows after Workbench Startup
See Nick's comment in bug 44296, comment 2.
This bug is also part of bug 28251, but since this bug here is more focused, I consider it the "better" report. Over on bug 28251, comment 1 I already posted some naive thoughts on how to tackle this in org.eclipse.ui.internal.WorkbenchPage#restoreState(IMemento memento,IPerspectiveDescriptor activeDescritor) or org.eclipse.ui.internalorg.eclipse.ui.internal.EditorManager#restoreState/saveState. Alas, this didn't work as I had hoped: It is quite easy to store the NavigationLocation in the mememento on shutdown. One can easily add this at the end of the SafeRunnable in EditorManager.saveState: // Save EditorLocation if (editor instanceof INavigationLocationProvider) { IMemento locationMem = editorMem.createChild(IWorkbenchConstants.TAG_LOCATION); ((INavigationLocationProvider) editor).createNavigationLocation().saveState(locationMem); } (and, of course, add the TAG_LOCATION to IWorkbenchConstants). The problem is, how to restore the cursor position on startup. When EditorManager.restoreState is called, the editors are created - according to the memento - but not fully initialized yet (createPartControl is not called). Thus one can easily read the NavigationLocations from the memento in EditorManager.restoreState, but cannot call restoreLocation(), since the editors are not yet ready to react on that (e.g. in a AbstractTextEditor the SourceViewer isn't set yet). :-( I have no idea on how to solve this. Maybe Nick's comment in bug 44296, comment 2 may solve this, by enabling editors to save their state themselves. If anybody has any other ideas on how to solve this, I would be happy to hear about it. Maybe I could even find the time to implement it myself.
This is not on the list for M8. Deferring....
Sorry, not for 3.0. Will consider post-3.0. If Editors want to remember cursor positions, they can use other mechanisms, e.g. preferences, resource properties. These mechanisms also have a longer lifetime, which may be a benefit.
*** Bug 28251 has been marked as a duplicate of this bug. ***
Nick, can this be reopened for 3.3 and implemented along bug 44296 comment 2? I investigated bug 124615 for 3.2 M6 i.e. restoring of the caret but hacking this into Platform Text and managing workbench start and shutdown is not something I want to do.
OK.
Can the priority of this be bumped up?
There are currently no plans to work on this feature. PW
Paul, as you can see in comment 7 I got the OK from Nick for 3.3. I have an item that is marked for 3.3 which depends on this one. It would be great if this could be reopened.
Reopened ... I assume we're looking at a saveState(*)/restoreState(*) type of situation? PW
yep, see bug 44296 comment 2.
Let's see if we can get something in by M4. Proposal: an editor part can implement IEditorPersistable as well and get save/init called on it like a view: IEditorPersitable extends IPersistable { /** * Extra lifecycle added to match IViewPart lifecycle. Refer to * IWorkbenchPart for basic part lifecycle. * * editor.init(memento) called after editor.init(site, input) on startup * if a memento is available but before the editor.createPartControl(*) * * editor.saveState(memento) will be called on workbench close * just like it currently stores the editor input. * */ public void init(IMemento memento); } IEditorPart is implementable by clients, so the new methods have to come in through a new interface. I'll investigate adding them to the EditorPart, though. PW
Created attachment 53564 [details] Add persistable API for editors First pass persistable state for editors. PW
Released API into HEAD >20061110 PW
Created attachment 53629 [details] NewEditorAction v01 Draft patch. If the NewEditorAction will create a new IEditorPart, allow IEditorPersistables to pass the saveState from the existing editor to the restoreState of the new editor. PW
I verified the IEditorPersistable is in M4, and if this is a fix that text can accept I'll release the new action patch into M5. PW
I gave this a try and it works as expected. Thanks. I would rename IEditorPersistable to IPersistableEditor. What's missing is a preference in the UI (General > Editors) where users can control whether they want this feature or not (some developers expressed that they would not like this behavior). However, the 'New Editor' action should probably not respect that preference. I suggest to set the default to 'true' and see how people react.
Created attachment 55588 [details] NewEditorAction v02 Thew new editor action patch adjusted for HEAD + IPersistableEditor. I'll re-test this patch after M4 I've released the IPersistableEditor to HEAD, and it will be in the next platform ui build submission. PW
Paul, I've released the restore code so that you can test. See bug 124615 for details and comments on remaining issues.
Released the New Editor action hooks into HEAD >20061220 PW
Dani, is there more to this bug to be investigated for M6 (more functionality you are waiting on), or is it fixed for M5? PW
see comment 18: the preference is still not here and there's bug 168524.
Ah, the preference. OK, moving to M6 PW
*** Bug 160978 has been marked as a duplicate of this bug. ***
*** Bug 41471 has been marked as a duplicate of this bug. ***
Ah, I understand now ... add the preference to General>Editors and if set to false, I won't treat anybody as IPersistableEditor. This doesn't sound like API, moving to M7 PW
>This doesn't sound like API, moving to M7 Mmmh - e.g. Platform Text and JDT Text have preference constants in API classes and I know of at least IWorkbenchPreferenceConstants in Plat UI. You'd better check before M6 is over ;-)
It should be OK. I'm doing the work in WorkbenchPage, then I can use our internal IPreferenceConstants. PW
Created attachment 62948 [details] General-Editors preference v01 This adds the preference to General>Editors. It defaults to true. If false, we won't ask IPersistableEditors to propogate state. Right now it is "&Use editor state persistance" and is above "Show &multiple editor tabs". If you have preferences about positioning or the name of the preference, I'm interested. Maybe "Persist Editor State"? PW
I'd prefer the word 'restore' instead of the more technically 'persist'.
Dani, sounds good: The best suggestion so far was: 1) move it to just above Close Editors Automatically 2) call it "Save/restore editor state" PW
Released to HEAD >20070404 PW
Paul, it should probably also mention that this only happens on starup, e.g. Restore editor state on startup Note sure if we could then even move it to the startup pref page.
(In reply to comment #34) > Paul, it should probably also mention that this only happens on starup, e.g. > > Restore editor state on startup How about "Restore editor state on open" since it also applies to "New Editor" actions as well? PW
But not if you simply open the file (e.g. via Navigator or Open Type). See also comment 18: >However, the 'New Editor' action should >probably not respect that preference.
OK, "Restore editor state on startup" and I'll revert the New Editor action to always respect the IPersistableEditor interface. PW
OK, "Restore &editor state on startup" and reworked so that it only effects the editors opened on startup. New Editor always uses the persistable state if available, and just opening an editor never from the package explorer (et al) never does. Released in HEAD PW
Fixed for the I build PW
In I20070501-0010 PW
