Open AngelEzquerra opened 9 years ago
That is a good idea.
Since every language has different error formats (e.g. some put the file name followed by colon, then a line numbers, others put the line number followed by a column number, etc) it would probably be a good idea to let the user specify some sort of per file type regular expression that would be used to detect the error message components (filename, line number, etc). Also, some languages put an absolute file paths, while others put a relative path. It should be possible to configure script-runner to work with both.
That makes sense, what I'm thinking to start with is a generic set of pattern matching filters which modify the output HTML. I wouldn't want to slow things down too much so perhaps I'll have to check this. The only major complexity I can see here is that we support a virtual PTY.
I wanted to add support for handling interactive input and also commands that expect to draw anywhere in the buffer should be supported too. Some of those things might cause issues with generic scanning of the output.
That seems like a good plan. I guess that if you wanted a command to be interactive, it would be ok to have to configure it as such somehow. Once configured as interactive, perhaps the generic scanning could be disabled by default?
I haven't done the ncurses implementation yet but if I have time I may work on it. Once I do that I'd be in a better position to know what is possible and what is not. I'll work on this at that time.
It should be pretty easy to add this now since we released 2.0.0 which uses XTerm. XTerm supports a linkify addon. Need to explore this.
When you run a script, and it fails due to some error, most scripting languages will show an error message containing the file and the line where the error was found. It would be nice if those paths were automatically converted into links that you could use to open the offending file at the offending line by clicking on them.