Extra chars in build results, messing with file_regex?

[parrots]

I'm trying to enhance the plugin for LESS (http://www.sublimetext.com/forum/viewtopic.php?f=6&t=1650) to include error reporting, but I'm noticing some strange output in the build results. Using terminal and building the LESS file I get the following:

Code: Select all

The "sys" module is now called "util". It should have a similar interface.
Syntax Error on line 33 in /Volumes/CSA Chester County/wp-content/themes/csatheme/less/style.less
32
33 html, body { margin : 0; padding : 0; 2}
34

However when I run the build I get this in the window:

Code: Select all

The "sys" module is now called "util". It should have a similar interface.
Syntax Error on line 33 in /Volumes/CSA Chester County/wp-content/themes/csatheme/less/style.less
32 
33 html, body { margin : 0; padding : 0; 2}
34 

[Finished]

Where are the extra characters coming from? Do I need to worry about them in the regex? I can't for the life of me get a valid file_regex and line_regex going and I'm wondering if they might be causing my trouble.

Edit: I'm thinking it might be the color information node.js is sending back for the error string?

[facelessuser]

In some terminals, you can specify colors with a special notation. That is what I believe you're seeing. Those extra characters are trying to specify color for the following text. The "[" lets the terminal know that the next number is the color, but since you are outputting it into an environment that does not handle that notation, you just get the extra characters.

[parrots]

Ah, thanks, looks like I need the -no-color options for lessc.

Question 2: for file_regex, is there a way to re-order the matches? I assume Sublime expects filename first, but in this case it's the last item on the line.

[jps]

I don't believe there's a way to reorder the matches, at least according to http://www.boost.org/doc/libs/1_38_0/li ... yntax.html

[parrots]

I don't believe there's a way to reorder the matches, at least according to http://www.boost.org/doc/libs/1_38_0/li ... yntax.html

So then there's no way to parse the above error message, since line_regex only gets called if file_regex doesn't hit (which it would).