Line numbers in plugins

I have a small ... a large problem with debugging a plugin.
The problem is this: the plugin in question is 847 lines of text long. When trying to install it I get 2 error screens. The first one (VBscript one) says that an instruction is expected at line 540. After closing that screen I get one in Muclient proper (the pinkish colored window with pluging parsing errors), that one says it has encountered a script error at line 327.

Now, I've tried scrolling directly to line 540 in the plugin, but there's no anywhere around there (which is what VBS is complaining about). Line 327 looks like the one with the tag. So I thought that maybe I need to find line 540 starting from line 327 :) But 327 + 540 = 867, which is greater than the total number of lines in the plugin.

I'd really hate to go line by line through the script, which is rather confusing, so maybe there exists a simple explanation for how lines are numbered in plugin files and how those numbers are referenced by the two error messages - the VBS one and Muclient one? In short - how do I find the actual number of the error line in the text file that contains the plugin from those error messages?

Code is counted at each line starting from the top of the file and including blank lines. You could, as this is a VB script, get a VB compiler and run the script thru it to find the errors.

The line count in the VB error message would be from the start of the <script> tag, assuming you have only one.

The line count for the plugin should be the end of the <script> section, hopefully.

If you email me the plugin I would hopefully be able to tie them together mathematically. :)

Ok, problem solved. Using Meerclar suggestion I saved the script in a separate file and loaded that under Scripting in MC. That gave the correct line number.

I am guessing that when compiling the script in the plugin, VBS is adding something to the beginning of it - in between the <script> tag and the first line of the script - perhaps the contents of the <include> file. That would explain those 100 something extra lines, if counting from the <script>.

Anyway, thanks Nick and Meerclar. And I'll be posting the plugin here as soon as I get it tested and cram some more things into it. Really hope it works - I already have a hard time figuring out what exactly it does myself, so if it starts acting up I'll be in serious trouble with debugging it :)

As someone who writes rather large plugins, I have been frustrated by this problem as well.

My plugin scripts are broken up repeatedly as I organize related aliases, triggers and script into different sections of my plugin file. To top it off, I also use "include" files which throw off the line count too.

Sometimes I try and remedy the problem by using: /World.Debug "Plugins"

The problem is, it's still not easy to calculate the line number, especially with multiple plugins installed, and that command prints the code for ALL of them to the output window.

So, I have a suggestion:

Modify World.Debug, or create new Debug option(s) which:

-Allows for specific plugin or main file debugging only.
-Redirects output to an external notepad window.

For example:

World.DebugToNote "Plugins"
World.DebugPlugin "AOD_EQ"
World.DebugPluginToNote "AOD_EQ"

I assume the filename would be generated automatically, perhaps something like "AOD_EQ-Debug.txt" or something like that.

Heh, it just occured to me now, as a workaround, I could use the current /World.Debug "Plugins", then copy the entire section related to my plugin to a blank notepad, and then use the notepad's line counter to easily find the line I need. The suggestions I just mentioned above would simplify the process somewhat. (I don't know why I didn't think of that before - Duh!)

Hmm. I use SciTE as an editor and I know it has built in debug support for attempting to execute scripts and such. When it runs one, it displays errors and I think hilights the line with the problem. The difficulty is that since the normal engine hasn't a clue what 'world.' objects are, I haven't really been able to test it.

However... It occures to me that since SciTE is available under Linux, PC and probably MAC, it is user modifiable (though I have been to lazy to change and recompile the XML lexer in it to color scripts right) and it does have a way to display error information, that it could be a helpful thing to let Mushclient interact more directly with.

The issues for doing this though are:

1. Mushclient needs to be more aware of when scripts use includes, so it can accurately report the right error line in the right file.
2. I am not sure you can call SciTE externally and pass it both a file 'and' the error line. The file yes, but that is useless without hilighting the error.
3. If Mushclient was more aware of such things, there is nothing to prevent making the notepad do basic stuff like showing the included lines with a different background and hilighting the error line itself. This wouldn't be as good as a full editor like SciTE, but would definitely be an inprovement over the current "guess where the real line is" method. ;)

However, it would mean having Mushclient parse the script, at least enough to find included code and VBScript's method of doing so leaves a lot to be desired, as in being nearly impossible compared to java, which I believe actually has a real include directive of some sort. They really short changed VBScript in a lot of ways. :p The only solution to this would be to actually make a function within the constants file (or some other common file) that impliments the loading of includes for VB, so Mushclient would simply look for instances of 'include("Filename")' or 'Variable = include("Filename")' when finding the places where such code blocks start.

There may be other useful things to add to that common set of routines as well, like 'sort', which VBScript also doesn't have.

Anyway, there is not much point of returning the line number in error, if the line is never right, but the solution definitely requires a bit of work, no matter how you look at it.

Hmm. Actually, thinking on it, another solution for VB would be a directive that the XML parser would see while counting lines. It isn't as though you could load this XML into a browser and it would work after all, so no need to be 100% complient with the implimentation. Basically usinng something like a compiler directive you could use #include ("Filename") and have the XML automatically incorperate the included script into the main body as it loaded. Both the engine and Mushclient would then have a complete copy and you could show the code in the #include block colored like I suggested, to differenciate it in an debug window (i.e. see the error and 'where' it is, but not edit.)

Besides coloring the included blocks, you could also have a right click menu item for 'open selected file in editor', to let them select the file name in the #include line (displayed in the debugger to show where the code block came from) and open that file. This would still create problems for java then, though...

There has to be a simple solution to this... Would a world.include command allow a running script to load new code maybe and use that in the parse step to get the right number of lines?? Then you would be back to the same situation again though. Sigh... Up to you I guess Nick, I don't have access to the programs code, so it isn't like I can do more than guess at solutions. ;)

If you did use the #include method though, then since Mushclient does load and parse all scripts, it would be removed and replaced with the actual included file anyway, even in pure vbs, js, etc, so it could be a good solution. Would have been nice if VBScipt didn't have this issue though and you could just look for the built in language specific lines for including such things... Serious mess.

Although I haven't seen the plugin the arithmetic would be like this - it isn't too hard.

You get a error line X (eg. 327 from your post).

You need two other things:

1. The offset of the <script> tag - use your editor to find that (eg. line 68) - call this A.
2. The number of lines in your constants.vbs file (or the file appropriate to your language). (eg. 122) - call this B.

Thus the line reported as an error would be X + A - B in your plugin. In my example that would be 327 + 68 - 122, that is, line 273 in the plugin file.

That is, subtract out the number of constants in the include file, as VBscript saw them, but they don't take up room in the plugin, and add in the offset of the <script> tag. Give or take 1 or 2, this should be the correct line.

It is a bit more complicated than that. Magnum for instance uses, I believe, multiple includes and since all of these 'probably' change the line the engine thinks it is executing... Then again, I don't use those, so I have no idea of that is true.

The solution I mentioned above is the best workaround. When you /World.Debug "plugins", the output includes your script fully assembled with all includes, etc. I get the feeling my post was skimmed over... sigh.

Would I do that?

Yes, your idea will give the best representation of which line is which.