Some points about plugins...

While the old script system is useful for backward compatibility, the only reason it is even worth anything anymore is because of those few functions that there are no plugin versions for. Oh, and main world triggers, etc. that need to have scripts, but... For instance, if you want to add a sound handler or additional MXP support that is not handled by the existing version of Mushclient, you have to put it in the master script. This is really dumb imho, since it means you can't easilly provide support of some special feature of a mud through such a system and then simply 'plugin' the feature. At the very least, we shouldn't force general users to edit a script, just to add functionality. That is what plugin developers are supposed to be doing.

It may also be nicer, since plugins are becoming the main method of doing things, if the menus for them could be gotten too through the same place as the rest of the world settings. Having them only under the file menu, instead of located and accessable in the Scripting tab or a Plugins tab is a bit odd at this point.

Frankly, I would almost prefer to see a means to edit the plugins internally and the old system phased out entirely, but I doubt that is practical, if for no other reason than it would require a way to edit or export, edit then re-import the script back into the plugin. Some editors 'might' allow that with some work, but not most of them. And with the limitations on Mushclient's notpad length and the lack of code hilighting or other features, we have to use an external program. Maybe the Linux version, which will likely need a built in scripting system anyway, could use a more integrated way to edit plugins, and avoid the master files for script, and even triggers, aliases and timers.

Personally, I recently moved a load of stuff to color combat output into a plugin. I then promptly forgot and tried to edit the main trigger list. When I realized my mistake I had to fumble through the file menu and plugin system to edit the dang thing. Same with parts of the main script I edit a lot. I 'should' move it to a plugin, but if I did, it would be difficult and annoying to edit it. Just moving the menu for them to where everything else is for a world would help a lot in that respect.

Eh, we should just break down and write a plugin editor stand alone.

Few enough people write plugins, and then edit them, to warrant adding it to MC. Personally I think it might be easier/better to do it via a seperate program.

For the windows version, quite possibly. Integration of an external application for that under Linux might be more complicated, especially with a C-like language that won't work with existing code highlight systems. Besides, for the existing version, I am just suggesting putting the menus some place that makes sense and extending some currently inconvenient to use functions to the plugin system as well.

I do think however that technically, the old design, in which triggers, etc. are an integral part of the world file, but the main script is in a completely different file only must sense now *precisely* because their is no consistant way to edit any of those things in the plugins themselves.

In any case, the only part of a plugin that couldn't technically be edited 'through' the existing system, with a bit of adjustment to handle plugins instead of just the main world, is the script inside it. I don't mind an external solution to that, but it is silly in the extreme to have to edit the entire plugin externally.

As for the existing world file... The only thing preventing everything in it dealing with triggers and the rest, including script, being exported directly to a plugin is those few callbacks that have no equivalent in the plugin system. If the menus where changed like so:


Why would this really be a bad thing? It might be nice to also have a 'script' subgroup to do the editing of that, but it is also possible to place the 'reinstall', 'edit' and 'remove' buttons all on the pages shown when you clicked just "Combat" or "Fred's Plugin'.

For 'Add', you click the "Plugins" sub-item itself, which give the same list as the current one through the exising menu, which also has Add, Edit, Reinstall and Remove. The only real issue is also adding a "Save Changes" option to each sub-menu, and some checks to ask you if you want to save the changes to the plugin you altered if you close the world. Just like you currently get with the existing world file if you change something.

Even if you still have to edit the plugin externally and then 'reinstall' to change the script in it, this would be an improvement.

As for the current Windows version, just moving and/or duplicating the main Plugin menu where it makes some sort of sense (and maybe even adding an additional icon for it) would make things a bit easier. The radical redesign I am suggesting for a future version is probably not practical in the Windows version, unless we get a non-line limiting notepad to use for editing and/or an external editor that can integrate well enough with Mushclient that 'save' in it will instead export the changes 'to' Mushclient, instead of to an external file. This would be possible through COM, maybe possible under Linux somehow, but they are just not designed to work that way (unless it is to "run" the script or compile code).

I agree in principle that a plugin editor should be achievable. Editing the script part would be tricky, but probably such an editor could concatenate the stuff between <script> and </script> into a single block, and you could edit it there.

The difficult part is if you use custom entities, otherwise it would be easy. Without custom entities MUSHclient could simply translate everything into "normal" text, and then translate back again to write it out. However if you have something like this:


<!ENTITY socials_command "socials" >


and inside the script:


world.Send "&socials_command;"


... if MUSHclient simply used its XML reader to read in the plugin (as it normally does) then that line becomes:


world.Send "socials"


... which would be written as that when you saved the plugin, which would throw away the customisation part.

On the other hand, if it does *not* translate any entities, then your script might look like this:



... which would be hard to edit.

Hmm.. True. I didn't consider entities. However, one advantage that a 'simple' color coding editor might have is that you could have an entity tab for adding/changing them, then color the parts of the script in the editor something that indicates it is an entity and not a literal value. It would mean treating the entire entity as a single character for editing purposes and maybe letting you use a right click menu to insert an entity into the script. i doubt an external one, unless it was specifically designed to work with Mushclient would support such a thing though. It definitely makes more sense from a readability stand point than either showing just the entities or mangling the editing by including the converted entities in it. Actually figuring out what the entity is could be done using something like the time stamp on the output. Once the mouse is over the colored block showing the entities value, you get a tooltip showing the entity name for it.

At least that is how I would consider solving that problem.

Erm, can you really just use &entity notation directly in the script? I was under impression that CDATA won't let you do that. I am working on an external plugin editor of my own, and though I haven't gotten to the script editor yet, I was thinking of having a tool for adding declared entities into the script automatically - you choose one from the list and it's added to the script at the current cursor position. I was thinking of saving positions of each used entity and tracking them through tracking the transformations of text, so that when saving I'll be able to know exactly which portions of text need to have CDATA broken around them. This is all theory right now though.

Well, Why dont you just have a list of entities, you are required to declare them at the beginning of the plugin, so whatever editor could just scan that, and remember that &socials is an entity. Then, it would translate other & sequences (&lt, &amp, etc), and disreguard (or color, etc) the &socials.

But yeah, since each entity has to be declared, we can maintain a list and perhaps even an entity editor type thing.

And yeah, compiling all the scripts into one thing shouldnt be too much of a problem, unless you were keeping your scripts next to the triggers that used them. But if you were using an editor like this, where perhaps you had linked things like that, you wouldnt need them to be physically next to each other in the script.

Enough of us are interested in this, perhaps we want to start a sourceforge project or something so we can all work together rather than in parallel.

You are right, you need to terminate the CDATA section in order to include the entity. This script fragment from my random socials plugin illustrates that ...



You can see how that would get messy to try to automate it.

I see what you mean, the problem looks pretty bad actually - if you read the entity outside of CDATA then its value will be substituted, if you save it inside CDATA then the parser will ignore its "entityness" when the plugin is loaded. Makes sense now, unless I am missing something again. Adding entities shouldn't be that big of a problem, but reading the already used ones looks bad indeed. The worst part about it is that entities aren't used all that much, but still would need to be supported. And it becomes even worse if you consider that entities don't necessarily have to be confined to just the script element.

I guess it could be done through extracting character data from all elements where it can be used (script, send, variable, what else?) in liew of the parser, using a normal file reader. Then somehow fish out entities from that data (using a regexp built from entity names OR'd together?) and break up the data section into a series of buffers. Then run the buffers containing "entityless" data through the parser to get fixed up string representations, and leave the ones containing entities as-is. Such a buffer could then look like this (Python):



Then, when passing that whole list to a text control for display, remember the number of lines and number of characters in the last line in each {} dict, and as the user adds text, figure out where it is being added exactly using MODIFY or CHANGE events and update the position properties for each dict respectively. When saving, use the positioning data to reconstruct the buffer and reverse the parsing process used for loading, placing CDATA breaks where appropriate. It would require massive mucking and testing, but that's just hard manual labour as long as the general scheme holds. I'll see if I can make a simple control just for this.

As for starting a Sourceforge project for this, I am all for it but there's a small problem with it for me and probably everyone else who could take part in this - I am using Python/wxPython for my editor. My expertise in VB is limited to whatever scripts I wrote for Mushclient in vbscript, a chess program written in Qbasic back in high school, and lack of any Microsoft developer tools whatsoever. My expertise in C/C++ is limited to a few small programs written for the sole purpose of figuring out pointer arithmetic, which fascinated me at one time :)