Menu
▾
▴
jedit-devel
|
From: Damien R. <dam...@gm...> - 2010-01-30 23:34:36
Attachments:
Clear_Properties.bsh
|
I wrote a small macro that attempts to clear all unused properties from jEdit. It works by maintaining a list of properties to keep using a set, then iterating through all of the defined properties and unsetting any not contained in the set. Properties to keep are determined by reading through some property files defined in the jedit jar (jedit.props and jedit_gui.props), properties with a special ending (currently just .shortcut and .dock-position), anything saved in a plugin's cache, and a few are added manually. From my quick tests it appears to work fine with no adverse effects, but I wanted to see how it works for others, and if it's stable enough then maybe include it with jEdit. Hopefully this will help speed up jEdit for anyone who's getting bogged down with a lot of unused properties. |
|
From: Shlomy R. <sre...@gm...> - 2010-01-30 23:52:09
|
I don't understand - is your macro based on a "working set", which is a growing set of properties which the user accessed recently (e.g. during the last week), or is it based on a "fixed" set of properties that includes what you wrote below? Either way, this can be quite risky to use. For example, some of my plugins define jEdit properties based on user input - properties that you won't find anywhere except the java code itself (they are not part of the .props files). A typical user is not aware of these properties (unless the user tracks changes to the properties file). At the very least, I suggest that the macro makes a backup of the current properties before clearing any properties that it considers unused. Shlomy On Sun, Jan 31, 2010 at 1:34 AM, Damien Radtke <dam...@gm...> wrote: > I wrote a small macro that attempts to clear all unused properties > from jEdit. It works by maintaining a list of properties to keep using > a set, then iterating through all of the defined properties and > unsetting any not contained in the set. Properties to keep are > determined by reading through some property files defined in the jedit > jar (jedit.props and jedit_gui.props), properties with a special > ending (currently just .shortcut and .dock-position), anything saved > in a plugin's cache, and a few are added manually. From my quick tests > it appears to work fine with no adverse effects, but I wanted to see > how it works for others, and if it's stable enough then maybe include > it with jEdit. > > Hopefully this will help speed up jEdit for anyone who's getting > bogged down with a lot of unused properties. > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > > |
|
From: Damien R. <dam...@gm...> - 2010-01-31 03:36:26
|
It does make a backup; it saves the properties file to properties.orig. And it's based on a fixed set; anything defined in the property files that come with jEdit or in any plugin's property file will be kept. I understand that it's somewhat risky, but I posted it to jedit-devel with the idea of making it less so. This was partly in response to your comment in the other conversation about there not being a way to clear out unused properties, and so this was my first step in attempting to accomplish that. Regarding properties defined dynamically, if there is a way to save those in the plugin's cache then there's no problem, because each plugin's cache is where the macro searches for properties to keep, not necessarily in the hard-coded .props file. |
|
From: Shlomy R. <sre...@gm...> - 2010-01-31 04:50:03
|
As far as I recall, the plugin's cache is built only when the plugin is loaded, and contains only objects that are included in the jar, not anything that is created later during runtime. To continue what I wrote in the other email, I think that cleanup of stale objects should not be automatic, as it's too risky. Instead, there should be a tool to present it to the user in the most user-friendly way possible, and let the user to decide what to delete and what to keep. Similar to my suggestion with project dependency types, it would be useful if each property was registered with jEdit, associating it with a meaningful description and the jar file that uses it (perhaps several jars). This would help the user understand which properties might still be needed, and in addition, jEdit would be able (with some overhead of course) to remove properties that are no longer needed - if all plugins that used a property are loaded, and the property is not registered by any plugin, it can be removed. Shlomy On Sun, Jan 31, 2010 at 5:36 AM, Damien Radtke <dam...@gm...> wrote: > It does make a backup; it saves the properties file to properties.orig. And > it's based on a fixed set; anything defined in the property files that come > with jEdit or in any plugin's property file will be kept. I understand that > it's somewhat risky, but I posted it to jedit-devel with the idea of making > it less so. This was partly in response to your comment in the other > conversation about there not being a way to clear out unused properties, and > so this was my first step in attempting to accomplish that. > > Regarding properties defined dynamically, if there is a way to save those in > the plugin's cache then there's no problem, because each plugin's cache is > where the macro searches for properties to keep, not necessarily in the > hard-coded .props file. > |
|
From: Damien R. <dam...@gm...> - 2010-01-31 17:24:06
|
That's definitely a better solution, but will take some time to develop if it's implemented. |
Thanks for helping keep SourceForge clean.
X