Websource silently fails on syntax error in ParserScriptAlbum part

Caused from a typo i had some problems today. My script contained the following line in the ParserScriptAlbum part:

regexreplace "(?<=<th colspan=.2.>).+(\d+)(?=:\s+

\s+)" "(Folge \1)"
I forget a 'p' in the command regexpreplace. However, i didnt get an error or any results from my script. It just finished after some time and showed up with all fields blank in the 'Adjust tag information' dialog. Nothing was written to the debug log, although turned on. If I deleted the debug logfile, no logfile has been created. In my case, information about previous commands that have been sucessful executed before the buggy line has been lost. No error was logged in Mp3tagError.log.

I could image two changes:

  • it would be nice to inform the user about the typo, somehow
  • the debug log should be written anyway

-u302320

For Notepad++ there is a very usefull language extension for the mp3tag web sources script language which highligts the comands of the script for a better overview. That helps to avoid typos, because you see they don't have the correct colour:
Web Sources Framework: Help needed

The latest Mp3tag language definition file for Notepad++ can be downloaded from there ...
http://notepad-plus.sourceforge.net/commun..._Mp3tag_mte.zip

... and for other Editors ...
http://cid-387b58366897ac93.office.live.co...%20Highlighting

DD.20110406.1917.CEST

It's for the Mp3tag Export Language, not the Mp3tag Web Sources Language.

Someone should stard a thread and collect & describe all these language plugins.

Ahh yes! I was blind for a moment or so. :sunglasses:

DD.20110406.2020.CEST

This kind of error should get logged to the scripterror.log file in %appdata%\Mp3tag\data

Yes, as a non-Notepad++ user I would appreciate a standard logfile that i could check. In the meantime I found another example causing this effect:

        moveline 0

which I tried as a shortcut of

        moveline -1
        moveline 1

I'm using this to reset the input buffer back to its original state.

-u302320

Please explain ... how can a 'moveline' command reset the input buffer to its original state, and what was the original state?

DD.20110419.1717.CEST

all replace and regexprepalce command are "reseted" if you use a moveline command which brings you back to the same line.

Yeah, this is one of the many missing things that I would like to be part of the documentation. As you've stated in the other thread, it is quite useful in some situations, indeed.

-u302320

So this situation can be understood as ...
... leaving the current line buffer by 'moveline' to anywhere implies to leave resp. to close the current line buffer and open a new line buffer for the new target line.
Just returning to the working line from before, will even cause a fresh new line buffer.
I tend to say ... there is no reset coupled to the 'moveline' command, but only a fresh initializing of the line buffer.

Executing 'moveline' to a line zero seems not to be valid, but this might be a matter how lines are counted in the file, zero based resp. one based.
Maybe a line buffer cannot be created for a line zero (which may not exist, respectively, which regulary does not exist), so that causes a runtime error.

DD.20110419.1812.CEST

Moveline is relativ (up or down), gotoline uses absolute line numbers. Thats why i tried moveline 0, to get back the unmodified buffer without actually changing the line. Anyway, my point was that I would like to get some info, why the script execution has been aborted.

-u302320