To answer the recent questions:
hhppyysobad, I see no reason why we can't look at Guass, winrats, stata, etc. Matlab was supported in CE if I remember rightly, so I see no real reason to discontinue such support. Plus it widens the potential userbase, which can only be a good thing.
JoBe, I also see no reason why TCL/TK shouldn't be supported.
Fenton: A lot of very good points here. Let me see if I can't provide an answer of an equal standard!
...we do decide to go with XML, there should be some tangible benefits for doing so. (snip)
Quite right. I don't want to add the extra processing time and code for XML if we can use a simpler format. On the flip side, it might help future development. I say might since if we put enough thought into the syntax format, we shouldn't have to worry too much about expandability.
Also, are there any reasons the syntax file would be used outside of EE's internal code?
There are reasons that this might be done.
1. Customisation. One of the strongest parts of CE was that the syntax system was set up so anyone could add syntaxes without too much work, and these could be shared. If they are integrated into the internal code, the option becomes removed.
2. Dual-coding. If we were to consider the above and allow external support files for custom scripts, you still have a certain amount of double-code in there, because you still have to handle any natively-supported syntax files, then
support external ones.
On to your other ideas:
a) a simple auto-completion wizard might just auto-complete keywords in the currently used syntax file...
I don't see why not. If you keep it literally to autocomplete known words, that shouldn't be too hard to implement in theory.
b) a complete-function wizard (similar to Excels formula wizard). For example, you type in "mysql_query("...
This has been suggested but it is very much an "on the fence" debate. On the one hand this would be a very useful feature (assuming the syntax file is complete enough to understand) but I am concerned as to the extra size that the program, and the syntax files, would have to be to accommodate this.
I also wonder whether this would take EE out of the line of "programmer's text editor" into "wannabe IDE", and if so it might turn people away rather than draw them in. It may be that "less is more," as some might say.
c) You might want to make the syntax files available for viewing on-line, perhaps as part of a manual...
Would there be much use for this? Many people I've known don't really care how it works, as long as it works. However, if the demand is there, XML would be a benefit, since XSLT or CSS could be applied instead of a pre-parse in PHP. (The server does run PHP and Python, and very shortly, Perl as well, and this is the sort of thing Perl would excel at)
I'm still not convinced that XML would handle a) or b) any better than a custom format, which can almost certainly be parsed and applied quicker than parsing and applying XML data. Normally I'd advocate the standardised formats etc, but I think here that speed, and size, will win out over the extra functionality that XML would provide - I simply don't think XML is best suited to this sort of application.
Every point is open for debate, and I'd rather us spending a few days debating it, and boiling it down to whatever will work best (or fastest or whatever is appropriate) before we build, since some things like this are pretty central to EE, and need to be set in stone *before* developing. Once set, we can implement it faster, we can implement it more effectively and make it work really well.