People said the same kind of thing when Java adopted Javadoc, however now almost all Java programmers use Javadoc. To say it is "impossible" to satisfy all scripts really has no basis. As I said, it is being based on a documentation scheme that does do it. So if it is based on one where it is possible, why would it be impossible here? As I said, it's far from perfect right now, but thats why I'm asking for suggestions. It can be done, it's just a matter of will it be done. If it were up to me, yes it would. But to suceed, others need to support it. I mean look at things like MTS. I thought it would fail miserably. But in reality it has become the de facto standard for creating themes in mIRC. Why can't the same thing occur here with documentation? If anything, MTS proven that if people in the mIRC community work together, they can accomplish standardization.
As for some people not using it, you're right, they probably won't use it if they don't do documentation now. But is that really a reason not to do something? A standardized, parsable documentation format is beneficial to both users and coders. Coders can now easily include the documentation right in the script code, which is very useful in large scripts. When you have 500 aliases in a single file, it's very easy to forget the syntax for each one. mIRCDoc makes it so the documentation is right there, and if you don't want to look through the file to find it, just use something like my /getdoc command which will give you the information instantly. Also, documentation never has to be duplicated. You know how many times I've seen projects (both mIRC scripts and regular programs) where the docs that come with the application don't match the ones on the website? People forget they have multiple documents that need to be updated. Then when they remember, they forget which part actually changed. mIRCDoc solves that as well. You simply would do something like /mircdoc2html and it would convert the mIRCDoc comments to an HTML format.
I agree, something like this will be difficult to get working fully, but since when is the fact that something is hard to do a reason not to do it? If you ask me, it's a challenge, and why not try and overcome the challenge rather than backdown? And even once it is fully working, it will be even harder to have it adopted, but again I refer to MTS, while you would be right in saying most people didn't recode their own theme engines to work with MTS, the people who were writing new themes did use MTS. And eventually, maybe years from now, the only themes available will be MTS themes. Why can't the same hold true here? Maybe everyone won't quickly go and reformat their documentation, but maybe people who are writing new scripts will use the format in those scripts. And eventually, the older scripts will have faded away.
