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).<br><br><br>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. 

<br><br><div><span class="gmail_quote">2006/10/23, Enrico Tröger <<a href="mailto:enrico.troeger@uvena.de">enrico.troeger@uvena.de</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Sun, 22 Oct 2006 02:01:29 -0200, "Alexandre Moreira"<br><<a href="mailto:alexandream@gmail.com">alexandream@gmail.com</a>> wrote:<br><br>> 2006/10/21, Enrico Tröger <<a href="mailto:enrico.troeger@uvena.de">

enrico.troeger@uvena.de</a>>:<br>> ><br>> > On Thu, 19 Oct 2006 11:45:12 +0200, nebojsa <<a href="mailto:nebojsa@anja.ig3.net">nebojsa@anja.ig3.net</a>><br>><br>> [snips here, there and everywhere]

<br>[snipped even more ;-)]<br><br>> I started using geany after thinking a lot of things that I would do<br>> in my own IDE, finding out I wouldn't have the time or skills to<br>> acomplish it (at least not in time to go back to  the project I

<br>> wanted to use the IDE for) and giving it up. Fortunately I found<br>> Geany to be quite good at many of my expectations.<br>Hehe, I know this. When I started writing C I used Anjuta. But the more<br>I worked with it the more I didn't like it. So I started to write a

<br>simple editor which fits my needs and this was also good practice to<br>learn C ;-). Then, 2 or 3 months later, I decided to publish the code,<br>it was Geany 0.1. At this point, all features that I wished me, were<br>

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...

<br><br>> Why am I talking this? Because I had this nice little idea when I was<br>> thinking about my "vaporware" IDE: I thought of having a "default"<br>> format for compiler error report, an abstract one, not based on any

<br>> default compiler. Something that would be easy for a computer to<br>> parse, with kind of message (error, warning, etc) , file name,  line<br>> number and all those stuff we need.<br>><br>> Then I could only design wrapper shell scripts to redirect the

<br>> compiler and treat the messages it throws, show them in the format<br>> specified by my IDE and all would work like a charm. Everytime I<br>> wanted a new compiler to report its errors to the IDE, I just had to

<br>> add a few seds or gawks here and there in a wrapper shell script.<br>><br>> With this in mind, perhaps it would be easier for those in need of an<br>> other compiler to just sed the exit with the regexes and reformat it

<br>> to whatever geany uses...a perl script would do a hell of a job<br>> there. What you say ?<br>Great idea. I don't think it will be a Perl script, at least as long as<br>I write it, but the idea is nice. Although, I think we will implement

<br>this in a different way. I don't like to use a Perl, Python, whatever<br>script because then we have a new dependency on that script language.<br><br>Shellscript with sed would be possible because it's available on nearly

<br>each Unix-like machine. But Unix-like...there is also Windows. Ok, at<br>the moment build support is completely unavailable for Windows but Nick<br>told he want to work on this sometime. So shellscript is again not the

<br>best idea.<br>But we have the GLib and we have it obviously under Windows too. And<br>GLib can process regexps I don't know how good but there is some<br>support. So we could put some regexps in a file and let them process by

<br>GLib.<br><br>And while writing this, another idea comes to my mind. Some time ago, I<br>rewrote most of the relevant code for parsing compiler output to be<br>more flexible and easier to extend. If you have time, have a look at

<br>src/msgwindow.c:392 in the function msgwin_parse_compiler_error_line().<br>There is a switch block to handle known compiler outputs. We could put<br>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.

<br><br>What do you think?<br><br>Hmm. I will talk with Nick about this and then we will see what happens.<br><br>Thanks for your support in Geany, your ideas, your translation.<br><br>Regards,<br>Enrico</blockquote><div>

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).

<br><br>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.<br><br>

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).

<br><br>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)...<br>

<br>Cheers,<br>Alexandre Moreira.<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">--<br>Get my GPG key from <a href="http://www.uvena.de/pub.key">

http://www.uvena.de/pub.key</a><br><br><br></blockquote></div><br>