I pushed version 2.7 out to release today.  This should clear up A LOT of complaints that people have with DOMercury. 

Because many people had problems with the DOMercuryAliases.xml being corrupt, I would advise people that had this problem to uninstall DOMercury and delete the DOMercuryAliases.xml before installing DOMercury 2.7  Deleting the corrupt DOMercuryAliases.xml is important. 

Here is a quick recap of the new features of 2.7:

• Eliminated re-indexing time period where plugin items do not show up in index and priorities are not set

Up until 2.7, DOMercury had the problem where, every once in a while, DOMercury would lose its skin and priorities or plugin items.  This has been fixed.  Priorities will no longer reset, and your clipboard item you need to manage all those code snippets will no longer mysteriously dissapear.

• Edited Priority Scheme so smaller file names have a higher priority

This one was an idea from someone else that I am angry with myself that I did not think of before.  Basically, for every 4 characters in an Item's name, its priority is automatically reduced by one.  This means that items with small file names (such as Paint, or iTunes) will not get taken over by loads of files with longer file names at the same priority.  This was a big problem with SmartSearch, as longer file names have the ability to match more search patterns that smaller ones do.  Now that DOMercury returns the smaller result first (unless priorities get changed manually or with extensive use) this will no longer be a problem.

• Changed ParametersProvider to supply IItems rather than objects

This only matters to Plugin developers (all 3 of us at the moment) Before, the ParamersProvider would return a list of objects, now it returns a list of IItems.

• Created two new interfaces: IDOMercury and IDOMercuryUserInterface for plugin interface extensibility

DOMercury's functonality is not the only thing that is plugin extensible anymore!  Now User Interfaces are as well.  A user interface in can be made for DOMercury using any .NET technology.  As you probably know if you are reading this far, I am (slowly) creating a WPF version of the DOMercury Interface.  After I get the hang of it, more will follow.

• Changed Options Form to accomodate multiple interfaces

This has to do with the above.  Now any options that have to do with specific interfaces will be handled by clicking the "Display Options" button in the Options Form.  This is currenlty where you will now go to change your skin.  Where the Skins tab used to be, there is now a new Tab called Interfaces, where you will be able to choose your DOMercury Interface.

• Added an EngineCore Interface to the DOMercuryInterfaces dll, the potential power of plugins has just increased drastically!

This again only pertains to developers, but it is a BIG deal if you happen to be interested in programming plugins for DOMercury.  Before you used to only be able to give DOMercury Items and actions.  Now, with the EngineCore methods exposed, You have access to functions that affect the state of the DOMercury Engine, such as setting sub indexes, retrieving Items form DOMercury's current index or main index, reactivating the DOMercury form, and so on.  This sounds both awesome, but a little scary as well, as a badly written plugin could potentially cripple DOMercury.  It will be known, however, that any plugins posted on the official Plugins page will have had its code specifically reviewed by me, and will be safe for your download and use.