Is there a simple way to integrate external tools like PyLint or JSLint? I know I can execute external tools (e.g. compilers), but how can their output (e.g. warnings, errors) be integrated into the code being displayed by Geany?
Any help would be greatly appreciated!
On Sat, 13 Sep 2008 14:03:37 +0000 (UTC) AC gmane.0vd@gishpuppy.com wrote:
Is there a simple way to integrate external tools like PyLint or JSLint?
Not ideal, but you could adapt one of the build commands.
I know I can execute external tools (e.g. compilers), but how can their output (e.g. warnings, errors) be integrated into the code being displayed by Geany?
I haven't used them myself, but custom parsing of error/warning messages is not implemented yet unfortunately (it's on the TODO list IIRC). For now it'll probably only work if they match the 'standard' interpreter error/warning syntax.
Regards, Nick
Not ideal, but you could adapt one of the build commands.
Adapt as in modify the compile or run command in /usr/share/geany/filetypes.*?
For now it'll probably only work if they match the 'standard' interpreter error/warning syntax.
I might be able to write a wrapper script to run the respective tool and reformat its output - however, I don't know what the "standard interpreter error/warning syntax" looks like... Also, If this is gonna be built into Geany soon, it's probably not worth the trouble!?
On Mon, 15 Sep 2008 14:14:55 +0000 (UTC) AC gmane.0vd@gishpuppy.com wrote:
Not ideal, but you could adapt one of the build commands.
Adapt as in modify the compile or run command in /usr/share/geany/filetypes.*?
Not really, they shouldn't be changed. Use Build->Set Includes & Arguments.
To keep compile and run, you could also add a Build command by editing ~/.geany/filedefs/filetypes.python:
[build_settings] linker=echo Python Build command...
For now it'll probably only work if they match the 'standard' interpreter error/warning syntax.
I might be able to write a wrapper script to run the respective tool and reformat its output - however, I don't know what the "standard interpreter error/warning syntax" looks like...
filename:line_no: some message
e.g. empty.h:4: Warnung: type defaults to `int' in declaration of `foo' empty.c:21: error: conflicting types for `foo'
Also, If this is gonna be built into Geany soon, it's probably not worth the trouble!?
Don't know if it'll be soon, maybe. When implemented it'll be a regex you can edit yourself.
Regards, Nick
filename:line_no: some message
I've written a simple wrapper script to reformat JSLint's (http://jslint.com) output - see below. That seems to work fine so far.
Don't know if it'll be soon, maybe. When implemented it'll be a regex you can edit yourself.
Looking forward to it!
---------------
import sys import subprocess import re
# settings -- TODO: read from cofniguration file cmd = "rhino" lint = "/usr/share/jslint/jslint.js" pattern = r"Lint at line (\d+) character (\d+): (.*)"
def main(args): filename = args[1] command = [cmd, lint, filename] output = subprocess.Popen(command, stdout=subprocess.PIPE).communicate()[0] print "\n".join(reformat(output, pattern, filename))
def reformat(text, pattern, filename): results = [] regex = re.compile(pattern) for line in text.split("\n"): matches = regex.search(line) if matches: line = int(matches.groups()[0]) char = int(matches.groups()[1]) msg = matches.groups()[2] results.append("%s:%d: [char %d] %s" % (filename, line, char, msg)) return results
if __name__ == "__main__": sys.exit(main(sys.argv))
Don't know if it'll be soon, maybe. When implemented it'll be a regex you can edit yourself.
This has now been implemented:
On Thu, 18 Sep 2008 17:08:40 +0100 Nick Treleaven wrote:
Done in SVN - for details, see the error_regex key in: http://www.geany.org/manual/dev/index.html#build-settings-section
Thanks a lot for that!
Is there an ETA for the next release yet? Not sure whether I can (or should) build from source...
Hi,
On Fri, 26 Sep 2008 13:02:28 +0000 (UTC) AC gmane.0vd@gishpuppy.com wrote:
Is there an ETA for the next release yet? Not sure whether I can (or should) build from source...
There are plans for a new release but nothing finalized by now. There are still a couple of things inside queue that needs to be done. So building from svn might be a good idea at this time ;)
Regards, Frank
There are plans for a new release but nothing finalized by now. There are still a couple of things inside queue that needs to be done. So building from svn might be a good idea at this time ;)
Ok, done that - compiling from source was surprisingly easy (Ubuntu 8.04: git clone ...; cd geany; ./autogen.sh; make; make install).
However, it seems the RegEx isn't working as expected: error_regex=(.+?):([0-9]+) When I click on the following error message: test.py:7:24: E202 whitespace before ']' ... the status bar says: Could not open /tmp/test.py:7 (No such file or directory)" So it appears the non-greedy matching doesn't work.
Am I missing something?
On Sun, 28 Sep 2008 09:32:40 +0000 (UTC), AC gmane.0vd@gishpuppy.com wrote:
There are plans for a new release but nothing finalized by now. There are still a couple of things inside queue that needs to be done. So building from svn might be a good idea at this time ;)
Ok, done that - compiling from source was surprisingly easy (Ubuntu 8.04: git clone ...; cd geany; ./autogen.sh; make; make install).
However, it seems the RegEx isn't working as expected: error_regex=(.+?):([0-9]+) When I click on the following error message: test.py:7:24: E202 whitespace before ']' ... the status bar says: Could not open /tmp/test.py:7 (No such file or directory)" So it appears the non-greedy matching doesn't work.
The regular expression you used from the manual is to match a different format that you have.
Try this one:
error_regex=^(.+?):([0-9]+):[0-9]+
Maybe it could be done better, I'm not good in writing regexps, but it works :).
Regards, Enrico
error_regex=^(.+?):([0-9]+):[0-9]+
Now I'm confused - that works. But all you added was the last bit (and the caret, which is not relevant here though). As I understand it (and testing in Python and JavaScript confirms this), the non-greedy indicator should render that last part obsolete!? While this seems somewhat off-topic, it might confuse other users as well.
On Sun, 28 Sep 2008 13:40:03 +0000 (UTC), AC gmane.0vd@gishpuppy.com wrote:
error_regex=^(.+?):([0-9]+):[0-9]+
Now I'm confused - that works.
Usually people are just happy if something works :).
But all you added was the last bit (and the caret, which is not relevant here though). As I understand it (and testing in Python and JavaScript confirms this), the non-greedy indicator should render that last part obsolete!? While this seems somewhat off-topic, it might confuse other users as well.
I'm not sure about the greedy operator but your error message contained not only filename:line but filename:line:column and because of the :column, especially because of the second colon, the regular expression of the documentation failed and the addition was necessary. Without this addition, it parsed "test.py:7" as the filename and "24" as the line number. With the addition, it detects there have to be two colons and it takes the filename as first reference, the line number as the second and then looks for a second colon followed by digits.
Regards, Enrico
On Sun, 28 Sep 2008 09:32:40 +0000 (UTC) AC gmane.0vd@gishpuppy.com wrote:
However, it seems the RegEx isn't working as expected: error_regex=(.+?):([0-9]+) When I click on the following error message: test.py:7:24: E202 whitespace before ']' ... the status bar says: Could not open /tmp/test.py:7 (No such file or directory)" So it appears the non-greedy matching doesn't work.
Thanks for pointing this out, I've now updated the docs (but the web docs might not be up to date until tomorrow):
*Example:* ``error_regex=(.+):([0-9]+):[0-9]+``
This will parse a message such as: ``test.py:7:24: E202 whitespace before ']'``
I'd thought GNU regex did support non-greedy matching, but evidently my initial tests weren't good enough to show they didn't. For reference, I have glibc-2.4-11 (Fedora Core 5).
Regards, Nick
Usually people are just happy if something works :).
Yeah, sorry about that - coders' curse, I guess...
I'd thought GNU regex did support non-greedy matching
So did I - after all, it's such an essential tool... Either way, I'm using an alternative RegEx now: error_regex=^([^:]+):([0-9]+)