Plugin development workflow

Hi,

My main plugin development workflow has always made heavy usage of the gui; adding triggers and aliases into the main world file, and using groups to separate triggers and aliases between plugins to manage them. However, I have so many triggers and aliases that it takes my screen reader a while to speak when i bring up the list of triggers/aliases (even when using the tree view option to control which groups are shown).

An alternative would be to export all the triggers and aliases and d script into an xml file and then edit it directly; that does sound a bit inconvenient for me as I like having the gui interface. I know that I can always add a trigger/alias on the gui and then copy and paste it into the xml though.

Would be interested to here the experiences of developers who use the xml directly as compared to the gui.

One thing you can do to reduce the list of triggers, etc. is to use filters. In the trigger list dialog you can click on the "..." button and enter a script, like this:



That would display only triggers with a sequence number of 42.

You could use that (or some other criteria) to reduce the list down to a particular couple of triggers.

---

Alternatively, you might make a "dummy" world which you only use for the GUI interface, to add (or modify) triggers and aliases. By doing them in a small dummy world you don't have to have listed all the triggers you aren't interested in right now.

You can use the Copy/Paste buttons to transfer to or from this world, to your plugin text.



I tend to do that myself, because often an alias is quite similar to a different one, just change the word it matches on and the script it calls, and you are done! Quite quick.

I am what you might call one of the more experienced MUSHclient script writers. I work exclusively in plugin .xml text files, and hate working through MUSHclient's GUI interface for anything other than single throwaway triggers or aliases.

1) My text editor allows me to set the terms of interaction with my plugin as a whole complex body of interconnected pieces without having to jump constantly back and forth between different interface dialogues. Everything I need is all in a single document. All of the functions I want to invoke, all of the triggers that invoke them, everything all completely searchable.

2) Related to 1, it allows complete separation of code for different projects. I don't have to worry about tripping over triggers or aliases that have nothing to do with the code project I'm working on.

3) Calling the same functions from multiple triggers or aliases without sticking those functions somewhere outside of the GUI is quite cumbersome, so working in text files makes code reuse much easier.

4) Perhaps not useful for someone using a screen reader, but as a fully sighted programmer I lean heavily on the very convenient crutch of syntax colorization in my text editor. It helps me read and write code faster without getting lost in a sea of variables, conditionals, operators, functions, constants, etc.

Another thing that working outside of the MUSHclient GUI gives me is the ability to do side-by-side direct comparisons of one version of some code with an older or newer version of it. This is particularly helpful for finding bugs introduced at known times.

What editor do you use?



How does your editor manage the fact that the plugin files are Lua embedded inside XML? (when syntax colouring)

Usually just gedit. ( https://en.wikipedia.org/wiki/Gedit )


I tell it that I want to treat them as Lua, because that's where I spend most of my time.

I've been using Geany recently. I found Gedit a bit limited in some respects. For example, doing a replace-all inside a selection only.

Plus it breaks out functions and variables by scanning the source, usually quite effectively. You can put the cursor on a function call and then get it to take you to the function definition.

I've been running into those sorts of problems as well, i.e having data from multiple plugins and scripts especially increases my risk of name collisions, so I think I'll switch to an xml based workflow.

Slightly off topic, but is it possible to call code from another plugin? For example, I was thinking a plugin that extracted information from the prompt, and then have it somehow giving this data to other plugins that needed it, rather than each separate plugin duplicating the same functionality.

Edit: the options I've found are BroadcastPlugin andCallPlugin, and it looks like BroadcastPlugin is what I want in this case. As numbers are used to denote the type of event being passed, is there a way to share an enum so that if I change the event numbers used by the plugin doing the broadcasting, that it doesn't break listening plugins? And is there a solution if I'm trying to pass a more complex type like a table?

Yes.

http://www.mushclient.com/scripts/function.php?name=CallPlugin

http://www.mushclient.com/scripts/doc.php?function=BroadcastPlugin

Heh you replied just as I was editing my original post.