Hey, I just found out I (AGAIN) sent the message to Enrico instead of sending to the list... so I won't snip it this time. This way everyone can read the past messages (if they want to).
After all that old-messages text there is my reply. Sorry for the inconvenience... I just can't help it. A bug in brain, perhaps.
2006/10/23, Enrico Tröger enrico.troeger@uvena.de:
On Sun, 22 Oct 2006 02:01:29 -0200, "Alexandre Moreira" alexandream@gmail.com wrote:
2006/10/21, Enrico Tröger enrico.troeger@uvena.de:
On Thu, 19 Oct 2006 11:45:12 +0200, nebojsa nebojsa@anja.ig3.net
[snips here, there and everywhere]
[snipped even more ;-)]
I started using geany after thinking a lot of things that I would do in my own IDE, finding out I wouldn't have the time or skills to acomplish it (at least not in time to go back to the project I wanted to use the IDE for) and giving it up. Fortunately I found Geany to be quite good at many of my expectations.
Hehe, I know this. When I started writing C I used Anjuta. But the more I worked with it the more I didn't like it. So I started to write a simple editor which fits my needs and this was also good practice to learn C ;-). Then, 2 or 3 months later, I decided to publish the code, it was Geany 0.1. At this point, all features that I wished me, were already present. Not that I don't like all the enhancements since 0.1 but I never thought I need it ;-). But it's not that important. I still like Geany(I think I should as developer) and that's all what counts for me. But I never thought that so many people could like it too...
Why am I talking this? Because I had this nice little idea when I was thinking about my "vaporware" IDE: I thought of having a "default" format for compiler error report, an abstract one, not based on any default compiler. Something that would be easy for a computer to parse, with kind of message (error, warning, etc) , file name, line number and all those stuff we need.
Then I could only design wrapper shell scripts to redirect the compiler and treat the messages it throws, show them in the format specified by my IDE and all would work like a charm. Everytime I wanted a new compiler to report its errors to the IDE, I just had to add a few seds or gawks here and there in a wrapper shell script.
With this in mind, perhaps it would be easier for those in need of an other compiler to just sed the exit with the regexes and reformat it to whatever geany uses...a perl script would do a hell of a job there. What you say ?
Great idea. I don't think it will be a Perl script, at least as long as I write it, but the idea is nice. Although, I think we will implement this in a different way. I don't like to use a Perl, Python, whatever script because then we have a new dependency on that script language.
Shellscript with sed would be possible because it's available on nearly each Unix-like machine. But Unix-like...there is also Windows. Ok, at the moment build support is completely unavailable for Windows but Nick told he want to work on this sometime. So shellscript is again not the best idea. But we have the GLib and we have it obviously under Windows too. And GLib can process regexps I don't know how good but there is some support. So we could put some regexps in a file and let them process by GLib.
And while writing this, another idea comes to my mind. Some time ago, I rewrote most of the relevant code for parsing compiler output to be more flexible and easier to extend. If you have time, have a look at src/msgwindow.c:392 in the function msgwin_parse_compiler_error_line(). There is a switch block to handle known compiler outputs. We could put the defined values in a file and then just read them. This would be the easiest solution(for us developers) and perhaps for users too because they don't have to write sophisticated regexps.
On the other hand are regexps probably more poerful and more flexible with some real exotic compilers.
What do you think?
Hmm. I will talk with Nick about this and then we will see what happens.
Thanks for your support in Geany, your ideas, your translation.
Regards, Enrico
Well, the Idea of using glib is great in the sense that we won't have to depend on "yet another library or language" and I am always in favour of such independent implementations (Yeah, my friend helping me in my project always complains about my behavior on this).
But, I have not much knowledge in Glib or Gtk+ for that matter... some Theory knowledge, but never done any good job at it. Bearing this in mind I cannot give any good advice on what would be a good format.
Ignoring my lack of skills, we could do something in the sense of having a kind of "chain of responsability" pattern, in that the file the user gives us would define a set of pairs : a match pattern and a substitution pattern [well, I am not quite sure if we would really need two, perhaps one is enough], and those pairs would be put in a simple data structure that would link together to form a list.
All that Geany would need to do is something in the line of the following pseudo-code: Get the message from the compiler. Fetch the first pair of patterns and put in "Pair". Loop: Pair is not defined ? Exit Loop. Does the message matches with Pair.match ? Yes: then substitute it using the second pattern and display it. No: Fetch next pair in Pair, Continue Loop.
It is not exactly THE "chain of responsability" pattern, but it is quite simple, not exactly resource intensive (I mean, we probably will have something around 5 pairs for a compiler (wild guess, I don't know the number of different message formats an average compiler generates)), and I think it would do the job.
To complete the idea, we could just add the messages that did not match any "match" pattern to the message window with a flag that indicates that it should not be "parsed" (to set file name, line number, etc).
Well, there is probably some flaws at my line of thinking, because all that came while I was studying for an exam, I'll take a closer look at the problem later, have some AI studying to do (hell I hate exams)...
Cheers, Alexandre Moreira.
--
Get my GPG key from http://www.uvena.de/pub.key