Some comments on word insertion issues...

Omit from Output is useful in many circumstances, but often impractical or completely impossible to use. This is bound to only become worse if Mushclient ever extends to support inline images or other similar things. An omitted line in some location where someone wanted to replace one word would seriously screw everything up if multiple fonts where involved, let alone some sort of inline images that may appear in the middle of it. I know, it would be real stupid but imagine something like this:

You see [small image here] floating in the air.

and the user wants to change that to say:

You see [small image here] -Backbiter- floating in the air.

Omit from ouput would either a) omit everything including the image or b) show the image on the wrong line, but let you insert the altered line after. In either case it would lose any font info too, like say the word floating done in something that looks like feathers (someone may actually thing this is a good idea..). This is even dumber imho if the line was just the first two words plus the image and all they wanted was to tack a word on the end of the line.

A better solution needs to be arrived at. One possibility is to add commands InsertText and InsertTextColour:

Insert (INTEGER character position, BSTR Text)
InsertTextColour (INTEGER character position, COLOR Foreground, COLOR Background, BSTR Text)

You would need to delay insertion until the sub ended and the client would have to shift the location of styles, or duplicate existing styles where the new stuff cuts it in half, as well as keeping track of the new offset for the next insert, but it isn't impossible. How thins effects situations like the image in the middle of the line... I suspect that would need to be a special style type that also gets shifted as needed. If you ever add more MXP support into the client, these things probably need to be considered prior to when they get added. There is bound to be things that work real well with text that won't work once you start imbedding images or other things.

However, the above idea would solve a number of irritating problems people have run into that involve text insertion. While it doesn't make 'quite' as much sense as having a special trigger, it is more practical, since I can't for the life of me think of a practical way to let a trigger insert text *and* color, especially if there are multiple insertion points.

Of course this probably doesn't fix the experiment I tried before, but... I still would, if debugging my own MXP, prefer to 'see' the defective tag in place, instead of using the complicated mess that the On MXP Error sub returns or using a debugging window that I can't use because it a) can't be positioned outside the client area and b) I don't like/want to cram it in under or above the world window. This is just a matter of personal taste I suppose, but I also find debuggers that tell me I have "Unknown error #324 on line 3165", but can't show me 'which' line that is in an IDE irritating as well. I hate command line debuggers for this reason. Mimicry of zMud and others behaviour should be an option and adding one flag to the MXP setting to allow it can't be that big a deal, even if you are an obstinate sob about it. ;) lol

I suppose the option could be added, but a couple of problems arise:

1. Once it exists, the motivation for server-writers to fix up their output will be gone - if you complain about things like "Press <enter> to exit" - where <enter> disappears and you get an error message, they will just tell you to turn the option on, rather than fixing the problem. Then, a year later, when everyone is used to having this option on, someone will want to add a genuinely new tag (eg. like <overstrike>) but it will actually appear in the output window, when with HTML browsers they do *not* display unknown tags, which is the desired behaviour.
   
2. As MUSHclient is processing an MXP tag it throws away things it considers irrelevant, like spaces, so that once it is done, if it can't find the tag in its internal table, it is not so easy just to put it back exactly how it was.

Hmm. Ok.

1. This is true, but how many successes have we had at getting anyone to fix this? Zero that I know so far. The fact is that the spec doesn't specifically state what to do and many people may simply assume that showing it is 'normal' behavior. In fact, unless Zugg specifically states otherwise, the lack of specific explaination of how to handle errors and his own client's behaviour may be considered the correct way. As stupid as it is, this isn't HTML. Even HTML itself ignores such things to such an insane extent that you can practically post a page that is so broken it does match any standard, save for the use if <> and still accidentally end up with something. This has caused no end of problems in developement and debugging.

I do see your point with extended MXP features though. It is an annoying complication, since it isn't exactly easy to capture valid but unsupported tags either as it is. Possible yes, but not easy. Maybe just a 'ignore these tags' list that lets you either pas them through out reject them completely. The way it currently works isn't exactly as flexable as it could be.

2. Ok, this I hadn't considered. I take it that the parser works like this:

a) found a <, start looking for functions
b) found a function, start looking for parameters
c) found >, stop

This is problematic, but not impossible to manage, it just means keeping track of the original text as it is read, including spaces and returning that if the flag is set.

This would be nice to have, if a reasonable solution could be found and annoying in some cases to go without. Simply displaying it also doesn't help anyone deal with tags that are actually valid, plugin supported and for some reason 'need' to have those spaces remain intact. For that you would need a much smarter On MXP feature, possibly a function that only told you something was wrong, gave you the entire tag and let you selectively continue through the process to reject/display it. This could work as a solution if it had 3 return values I suppose, like 0 = treat normally, -1 = ignore, -2 = display. There are bound to be cases where simple mimicry of zMud isn't as useful and such a thing would allow the user to decide which one to do. However it would also, I suspect now, require building the *tag* and passing it to the function, before the MXP parser did anything with it. One more step to slow things down, but it would allow the user to decide what to do with invalid tags, a better way to deal with special unsupported ones and display any they don't want the MXP parser to deal with at all. I don't see a better option that covers all situations. :(

----

Anyway, even if the MXP thing isn't solvable I would still like to see the InsertText and InsertTextColour idea, which would be definitely be quite helpful.