I have been thinking about this and if needing to use CDATA
within a <script> tag is part of the XML spec, then the only reason I can see that it would be is do to another one of those, "It worked that way since version 0.02alpha, so if we fix it the web pages won't load right." sort of things. :p
Imho the function of CDATA should be implied by the <script></script> tag combo. It makes no sense for code, which is almost always using & or other such things to need to be defined that way. If the mushclient files where intended to load in a browser then I could see it as being reasonable, if such is needed there, but not when used in mushclient. It also wrecks havoc in code editors like SciTE which, when they see CDATA, stop color coding the source within that block. Is there any real reason to support such a goofy cludge?
The only real alternative would be to "escape" every <, > and & as < etc. (which you can do if you want to). I suppose you could only look for </script> but that is a pretty horrible cludge too, and is then departing from standard XML.
I wanted MUSHclient to use standard XML, not some local variant. If you load the plugins (or world files) into IE or Netscape they render correctly, which shows that they are standard XML.
Unfortunately, MXP is 'based on XML' but not really XML, so parsing MXP needs a custom parser. I wanted to get away from that with MUSHclient, so if you can find an XML parser, you can use it with MUSHclient plugins, world files etc.
Ok. I can understand your reasoning. I do think that this looks a lot like another example of the hack jobs they do on browser implimentation. It just seems really strange to me to provide an entity that expects code that may contain other entities and force you to use CDATA to fix it, because the parser isn't bright enough to know it should leave it alone. oh, well.. Guess I will have to break down and actually figure out how to make a new lexer for SciTE that supports the scripting correctly and colors internal mushclient stuff something other than the vbscript keyword color. :p
Unfortunately I can't just create a new one, package it in a file and post it someplace, since the guy who wrote SciTE made it so new lexers are compiled into the master dll. :p Bloody inconvenient imho.
If it is a script it should be treated like one, not like a chunk of text.
I see your point, believe me, but I want to stick to standard XML. For one thing, MUSHclient parses its XML in two distinct phases:
1. A "lexical" parse, which merely reads the XML from the document (or clipboard) into memory tables (linked, nested lists). This lexical parse checks for a "well-formed" XML document, handles entity substitution, comments, CDATA etc.
It checks that <xxx> is followed by </xxx> and so on.
2. A "content" parse, which looks for elements that MUSHclient actually knows about (eg. it looks for "<world>", "<script>" and so on. Ones it recognises get interpreted, ones it doesn't get a warning message (eg. unknown option "blah").
Phase 1 could be used on any XML document, and it is in phase 1 that it needs to be able to handle "<" signs and so on. Thus, the way I have done it, it doesn't realise that <script> is special - I know it could be added on as an exception, but I don't want to do that. It destroys the nice elegance of it.
As for the syntax colouring, you could always strip out the scripts into another file, or comment out or remove the CDATA block if they are annoying your editor, and put them back afterwards. (eg. change all CDATA to blah, and change them back before saving).
Dang.. While you where readind my post I nosed around to what the heck they where thinking, then came back to change it. And while doing that you posted again. lol I think the main problem here is actually that XML is not a document (they may claim it is, but...). Rather it is a container, as such the rules are different, sadly that means things like coloring the blocks that contain scripting the right way doesn't work, since the container, and this the editor haven't a clue that it is looking at scripting.
Like I said. One of these days I need to write a new lexer for SciTE, or better yet an editor that I my be able to hand you the code for so we can stop fiddling with external editors that don't speak mushclient. lol
The problem I have is not apparently that it doesn't recognize scripting (the <script> tag causes the CDATA to be non-colored), but rather because the XML lexer is missing the ability to color the code. :p This is the thing that bugs me about SciTE. Instead of using some standard routines and letting you define keywords like:
keywords.group1 = for,next,exit for
class indent group1 color=blue,white font=fixedsys
it uses custom dll routines for each language and any new keywords you add end up in the default color. Also in cases like XML, you can't fix the lexer to support script code without downloading the source and recompiling. There has got to be some better way of doing that. :p
Anyway.. I think I saw the one you mentioned before though and rejected it because it didn't already directly support all three script types the mushclient can use, doesn't currently appear to support XML at all and I would have to pay to use it. For something I have to pay for I expect it to already provide support for 20 languages, not merely "be able to". Even if it is difficult to modify, SciTE already exceeds ultraedit in that respect with 36 languages supported and no limits on the number you can add. I just wish they had thought about making it a bit easier to do.
UltraEdit has the easily modifyable dictionaries you're looking for. Yes, it 'only' supports 20 languages at a single time, but it's dictionary is just a wordlist.txt file.
For your convenience the author made available http://www.ultraedit.com/downloads/additional.html and there's a hell of a lot more than 36 languages there (roughly 370 in the AllFiles.zip). :) I don't know 36 different languages, or even 20 different ones, so having the option to highlight any 20 differrent programming languages easily, and every language just a cut-and-paste away is beautiful.
The amount of editing I do made the $35 trivial considering all the features it has...
(Telnet's free too, but I like Nick's product better. :))
>(Telnet's free too, but I like Nick's product better. :))
Comparing apples and oranges are we? Or in the computer world equivalent, comparing the old Apple II OS to DOS with 4DOS installed. lol Having nosed around the Mud Master site recently I would have to say Mushclient is not the only good one around any more, since MM is at least as extensible as Mushclient, but like SciTE it is a lot harder to code some things for it (The scripting looks scary..), so even free vs. fee programs is not a good arguement. You don't always get what you pay for and if you are on a budget even having someone ask you to pay for it is a major turn off. ;)
In any case.. I prefer to stick with something I know works for now. I may, if I get really annoyed, eventually try to code one myself (that actually has some real code checking, etc.) In the long run though Gammon definitely needs to replace Mushclient's limited notepad with something that better supports both large documents and the scripts we use. As it is, since they can't be dropped outside the client window or set to be on top, etc., the existing notepads very quickly become mostly pointless.
Gammon definitely needs to replace Mushclient's limited notepad with something that better supports both large documents and the scripts we use
Just set the script configuration to call an external editor. That way the window is outside the MUSHclient window, and it will handle a larger document, have syntax colouring, etc.
Miss most of the conversation Nick? We where talking about external programs, but it is alsways easier to work with something the was built to handle what the program uses, than use something that only partly supports it. This is why I don't generally use a code editor designed specifically for C to edit Basic. ;)
In this case I have two problems. The first being that I can't sepecifically set mushclient commands in their own color and in XML, I can't get any coloring. Fixing it requires custom coding and a recompile. I could use WillFa's suggestion, but I have yet to get into a sufficiently financially stable position to pay for your client. I definitely don't need to use an editor that I also have to pay for and will not be able to use at all do to the registration cost.
A better solution is for mushclient to not be stuck with a 32k limited, window limited and non-code aware notepad. Even things like sending text to the notepad from scripts is probably easier to do with a seperate COM program, than the existing notepad, because you can't put the dang notepad any place, but in the client window (and often underneath everything else that's going on). I am not the only one to say this. It is among your list of suggestions after all.
In the mean time I am stuck with only two real options and both have what I consider to be serious flaws. ;)