Bugzilla – Full Text Bug Listing
| Summary: | [preferences] Code folding has completely disappeared | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Mark Melvin <mark.melvin> | ||||||
| Component: | Text | Assignee: | Dani Megert <daniel_megert> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | david_williams, mik.kersten | ||||||
| Version: | 3.2 | ||||||||
| Target Milestone: | 3.2.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Mark Melvin
Created attachment 47700 [details]
A bunch of screenshots
Created attachment 47701 [details]
My eclipse configuration
Actually, I just saw this in my exported preferences: /instance/org.eclipse.jdt.ui/editor_folding_provider=org.eclipse.mylar.java.ui.editor.foldingprovider And I don't have Mylar installed. I'm betting this is the problem. I'll try to get rid of it and see what happens. Nevermind! That was it. I'll set this to INVALID. Sorry for the noise. Mark .. I'm not sure this was noise. I assume you had mylar installed at some point, it (or you) set some preference data, and then you uninstalled mylar. Seems a normal scenerio ... and seems there ought to be some way to (easily) filter out preferences of things no longer installed. ... easier than asking users to had edit their preference files :) Any suggestions? Based on how you, presumably, got into this state? Well, I think the actual sequence of events here was: 1) Installed Mylar because it was cool. 2) Exported my preferences at some point to keep my comment templates, etc. 3) Found Mylar was locking up my Eclipse occasionally so I removed it. 4) Some point down the road, I upgraded my Eclipse to 3.2, then re-imported my *old* exported settings to get my comment templates back. So, basically I think I imported a set of preferences that was both from an older platform (maybe an earlier milestone build of 3.2 - or even 3.1?), and contained preference settings from non-existent plugins. I assume the persisted plugin version ensures that only compatible preferences are imported, although I am unsure what algorithm it uses. But there is another dimension. Normally, I just upgrade my Eclipse when a new version comes out, then open it up on my old workspace. So, what happens in this case? There are two ways you can get version conflicts here. Through importing preference directly, or through opening an old workspace with old preferences persisted. Is this handled differently or the same? I'm not sure. I guess the problem here was not so much that the preference *key* was from a non-existing plugin (I assume that wouldn't have caused a problem), but rather the preference *value* pointed to a non-existing class. I guess it could be a JDT bug then. Hi Mik. Is this another (like code assist) where Mylar hijacks JDT Text features and leaves them in a bad state once Mylar isn't present? >Seems a normal scenerio ... Well, no. We are not supposed to expect that people replace stuff (e.g. JDT code assist or folding) with their own unless we provide clean extension points. Ways to prevent this in the future are - we make more code private - we throw exceptions when we detect that we are hijacked and things aren't as they should be Of course we don't do this and are friendly but expect others to be as well but as a reward we get blamed - not a normal scenario if you ask me. >Any suggestions? Based on how you, presumably, got into this state? Now that we know we can force our folding provider to be installed again once we detect that the current one doesn't even exist. Mik, can you confirm this? Just to clarify the 'hijacks': in this case I think Mylar didn't do anything bad i.e. I assume it correctly adds a folding provider via extension point and uses preference API to set this one to be the default. The problem is that this is done via special Mylar customization UI/wizard which is later no longer available and the user is not aware that he changed preferences that he could as well change in the preference UI itself. We will have to add code that reverts to the default folding provider in case the current one is not present. NOTE: this trick does not work for normal int, boolean or String preferences that get changed by a plug-in and that is later deleted from an install. Fixed in HEAD and R3_2_maintenance. I just wanted to say "thanks Dani". While we can't all cases of "bad preferences", as you point out, fixing the cases we can is a much appreciated attention to detail. And who ever comes up with a general automatic solution will undoubtedly be nominated for the Nobel Prize. :) Just catching up on this now (was away on vacation). Mylar for Eclipse 3.1 had a custom folding provider (via org.eclipse.mylar.java.ui.editor.foldingprovider). Mylar for 3.2 uses the standard Java folding provider. So yes, it looks like a preference value for a non-existing provider was imported. This case was handled gracefully if the user updated from the 3.1 to the 3.2 version of Mylar, but not if they imported old preferences. But the reverting to the default value of the provider is not defined definitely seems like a good idea since another plug-in could do this. Dani: the only place that it was possible for Mylar's strategy of extening JDT to leave a preference value like this undefined was the content assist computer, which was resolved by bug 140416 as you indicate. Mark: if you try an up-to-date version of Mylar and see any of the lock-ups that you refer to please file a bug report. verified in M20060830-0800 |