|Sort, why wouldn't it make more sense to adjust the behaviour of the plugin load wizard so you can "set" which order they need to load, and thus execute in? Scripting the loading of scripts is fine, if you know how to do it, but some people wanting to use the plugins may not want to even try to learn how to do that, just use the existing plugins.|
Or, actually, in this case we are actually also talking about what might be called "dependencies". I.e., to create consistent behaviour in plugins B, C and D, you need to make sure A exists to feed them the information, persumably in the right order. It might be up to the coder of A to check what plugins are "actually" installed, so they figure out the right order to send them messages (in some cases), but you still need to make sure A is loaded. So.. Your actually talking about setting things up like:
1. Mushclient plugin list - Tell the loader, "Plugin A **must** be loaded before B, C or D."
2. Plugins B-D - list "in" the XML a <Dependencies>Plugin A</Dependencies> feature. If A fails to load, so do B, C and D, and errors are generated to show *why* they failed to load. (Because A wasn't loaded correctly first or failed to load correctly.)
In fact, point 2 would tell someone if they forgot to set point 1 correctly in the plugin load list. Since if they tried to load C, B, A, then D, only A and D would correctly load, the other two would generate an error like, "Plugin C: This plugin requires Plugin A to be loaded first. Plugin not installed."
Isn't it fun the sorts of non-trivial things that can pop up in stuff you *thought* worked right to start with? lol
Oh, and.. It might even be useful to have a setting for "Plugin warnings", which would include things like, "Warning, this plugin uses Omit From Output, which could potentially interfer with the correct operation of other plugins. Setting the load order for this plugin to load after other plugins may prevent any problems caused by this." In other words, if the parser knows a conflict "could" happen, and warnings are turned on, you get a clear debug message telling you "why" the plugin might be causing other plugins to got wonky and how to maybe fix it.
Though, just for the sake of reasonable design, another alternative is to cache the original line, then have each plugin process the line, *as though it was never omited*, even if something has already done so. Not sure if that change would be any worse than altering the way plugins load and making dependecy checking work, or even *if* there is some unknown problem with that. Only thing I could think of is the obvious funny of having two plugins omit and both produce a replacement line, the line only being removed "once" by the first plugin, but both of them generating their lines based on the assumption that its still there in the second plugin. lol Even then, a warning, such as, "X plugins appear to both omit the same lines." might be nice, to warn you this is going to happen, if you have warnings turned on. In fact, if you warn about omit at all, you kind of want to warn about that case as well. And that unfortunately isn't too easy, since comparing identical triggers is one thing. Comparing ones with "identical function", but different design... may not be possible.
Damn, you really opened a can of worms here. lol