Hi I;ve been playing with this method (I added to my plugin api)
geany->msgwindow->compiler_add
and it works great, but even if I send my message as file:line:type:msg, I get an assert failure from the message parser (i don't have it in front of me, something about "filename"), is there something special about the format of the message or something else I should know about when trying to use this?
Thx
bd
On 09/10/2007 07:16:50 PM, blackdog wrote:
Hi I;ve been playing with this method (I added to my plugin api)
geany->msgwindow->compiler_add
and it works great, but even if I send my message as file:line:type:msg, I get an assert failure from the message parser (i don't have it in front of me, something about "filename"), is there something special about the format of the message or something else I should know about when trying to use this?
So you are writing a custom build process? It's probably that the build_info struct in build.c doesn't have the right information (e.g. build_info.dir). It's needed for msgwin_parse_compiler_error_line() to work correctly.
Regards, Nick
As a by product of my code completion with the haxe compiler I get syntax checks for free too on the pressing of ; in this case, so I want to add the compiler output to the compiler window at that time. I'll check the build.c later today.
Hey how long do i have before the next release is due? There are still some things I'd like to get in.
Thanks
bd
On Tue, 11 Sep 2007 11:50:36 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 09/10/2007 07:16:50 PM, blackdog wrote:
Hi I;ve been playing with this method (I added to my plugin api)
geany->msgwindow->compiler_add
and it works great, but even if I send my message as file:line:type:msg, I get an assert failure from the message parser (i don't have it in front of me, something about "filename"), is there something special about the format of the message or something else I should know about when trying to use this?
So you are writing a custom build process? It's probably that the build_info struct in build.c doesn't have the right information (e.g. build_info.dir). It's needed for msgwin_parse_compiler_error_line() to work correctly.
Regards, Nick
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
On 11/09/07 14:02:34, blackdog wrote:
As a by product of my code completion with the haxe compiler I get syntax checks for free too on the pressing of ; in this case, so I want to add the compiler output to the compiler window at that time. I'll check the build.c later today.
Cool.
Hey how long do i have before the next release is due? There are still some things I'd like to get in.
Perhaps not long ;-) It depends what you want to add - if it's simple things to append to the plugin API, they can probably be added before the next release.
Regards, Nick
Hi Nick/Enrico
I got back to this again, but to add BuildInfo into plugindata.h, it seems like the other plugins would need to include build.h too, as you don't include .h's in plugindata.h for some reason.
So, given that this is late in the day, maybe for now I can just add into struct GeanyData, void *buildInfo and set it up like this
geany_data.build_info = &build_info;
in plugins.c, then it won't affect anything else before release, and for the next release we can think on it harder?
Would this be acceptable to you now? If pls find attach patches for r1883
thx
bd
On Tue, 11 Sep 2007 15:56:22 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 11/09/07 14:02:34, blackdog wrote:
As a by product of my code completion with the haxe compiler I get syntax checks for free too on the pressing of ; in this case, so I want to add the compiler output to the compiler window at that time. I'll check the build.c later today.
Cool.
Hey how long do i have before the next release is due? There are still some things I'd like to get in.
Perhaps not long ;-) It depends what you want to add - if it's simple things to append to the plugin API, they can probably be added before the next release.
Regards, Nick
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
On 9/15/07, blackdog blackdog@ipowerhouse.com wrote:
So, given that this is late in the day, maybe for now I can just add into struct GeanyData, void *buildInfo
As long as you declare it as a pointer to a struct, and you don't try to dereference the pointer before including the header, I think you can just do it this way, instead of void pointer :
struct BuildInfo *build_info;
Also IMO it is always a good idea to add new fields to the *end* of a struct, to keep the existing offsets the same.
- Jeff
On Sat, 15 Sep 2007 12:00:12 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On 9/15/07, blackdog blackdog@ipowerhouse.com wrote:
So, given that this is late in the day, maybe for now I can just add into struct GeanyData, void *buildInfo
As long as you declare it as a pointer to a struct, and you don't try to dereference the pointer before including the header, I think you can just do it this way, instead of void pointer :
struct BuildInfo *build_info;
Yes but it seems then i need to include build.h in various files then.
Also IMO it is always a good idea to add new fields to the *end* of a struct, to keep the existing offsets the same.
I did that to start but all the struct fields are grouped at the top of the struct and have nulls assigned to them later in order, so not knowing better i thought best keep the form of the existing.
I'm not sure so if Nick or Enrico can tell me what's best I can resubmit.
Thanks for the pointers.
bd
- Jeff
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
On 15/09/07 18:29:15, blackdog wrote:
On Sat, 15 Sep 2007 12:00:12 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On 9/15/07, blackdog blackdog@ipowerhouse.com wrote:
So, given that this is late in the day, maybe for now I can just
add
into struct GeanyData, void *buildInfo
As long as you declare it as a pointer to a struct, and you don't
try
to dereference the pointer before including the header, I think you can just do it this way, instead of void pointer :
struct BuildInfo *build_info;
Yes but it seems then i need to include build.h in various files then.
You don't have to include build.h in that situation, but the problem was that struct BuildInfo wasn't declared in build.h - I've now fixed this and applied the patch slightly modified - thanks for this.
I also changed compiler_add in the API to take printf style varargs - I think this is more flexible.
Also IMO it is always a good idea to add new fields to the *end* of a struct, to keep the existing offsets the same.
I did that to start but all the struct fields are grouped at the top
I like to keep the data fields grouped together, so I think this is OK. I incremented the abi_version so plugins will need recompiling.
Regards, Nick
On 9/17/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
I've now applied the patch slightly modified - thanks for this.
Hey, I like this!
I would also like to be able to clear any existing messages, and activate the notebook tab. It looks like the easiest way would be to add a reference to the global struct MessageWindow into the struct GeanyData. I can work up a patch if that sounds OK. ( I would call the field msg_win since we already have a msgwindow )
Also, I'm not sure what sort of housekeeping I need to do when I assign the build_info.dir string. I assume that if it's non-null to begin with, I would need to free the existing string, but then who is responsible to free the new string that I allocated?
- Jeff
On 17/09/07 22:56:35, Jeff Pohlmeyer wrote:
[...] I would also like to be able to clear any existing messages, and activate the notebook tab. It looks like the easiest way would be to add a reference to the global struct MessageWindow into the struct GeanyData. I can work up a patch if that sounds OK. ( I would call the field msg_win since we already have a msgwindow )
I think it might be best to avoid exposing the MessageWindow fields - would a single function to clear and focus a message window tab be sufficient?
Also, I'm not sure what sort of housekeeping I need to do when I assign the build_info.dir string. I assume that if it's non-null to begin with, I would need to free the existing string, but then who is responsible to free the new string that I allocated?
Whoever sets the string. If you like you could use:
#include "utils.h" ... setptr(build_info.dir, g_strdup(new_path_str));
Regards, Nick
On 9/18/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
I think it might be best to avoid exposing the MessageWindow fields - would a single function to clear and focus a message window tab be sufficient?
Yes, that would be even better, but ...
My idea here was to use the compiler window to display error messages caused by faulty scripts invoked by the Lua plugin.
But after thinking about it, that is probably not such a good idea.
For one thing, the compiler window appears to be disabled on Windows, so it wouldn't work there anyway. Also, the Lua interpreter stops on the very first error it encounters, so it doesn't spit out five thousand lines of obscure error messages like gcc loves to do.
So I think the best approach for me is to simply display a dialog box describing the error, with maybe a "Go There" button to open the script and scroll to the offending line. That should be easy enough to accomplish using the current API.
So in other words, never mind all my noise!
- Jeff
Hi Jeff
Also, the Lua interpreter stops on
the very first error it encounters, so it doesn't spit out five thousand lines of obscure error messages like gcc loves to do.
I'm using this as a feature in haxe, so that I check the syntax per line on the press of a ; , then I output the syntax error if there is one to the compiler window, works quite well.
bd
On Tue, 18 Sep 2007 14:13:03 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On 9/18/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
I think it might be best to avoid exposing the MessageWindow fields
- would a single function to clear and focus a message window tab be
sufficient?
Yes, that would be even better, but ...
My idea here was to use the compiler window to display error messages caused by faulty scripts invoked by the Lua plugin.
But after thinking about it, that is probably not such a good idea.
For one thing, the compiler window appears to be disabled on Windows, so it wouldn't work there anyway. Also, the Lua interpreter stops on the very first error it encounters, so it doesn't spit out five thousand lines of obscure error messages like gcc loves to do.
So I think the best approach for me is to simply display a dialog box describing the error, with maybe a "Go There" button to open the script and scroll to the offending line. That should be easy enough to accomplish using the current API.
So in other words, never mind all my noise!
- Jeff
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany