Hello,

Okay thanks it compiles now :) But I still have a problem with a function which is into sciwrapper.h. When I launch geany and open the debug messages it says :

Can't load plugin: /usr/local/lib/geany/pretty-print.so: undefined symbol: sci_scroll_columns

I also added the -Wall options into Makefile.am and no warnings is printed when I compile (in fact it seems to find the right function), but the linker don't.... Any idea ?

Thanks & regards, Cedric

On Sun, Aug 16, 2009 at 8:50 PM, Colomban Wendling < ban-ubuntu@club-internet.fr> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi,

Cédric Tabin a écrit :

...

I just try to include sciwrappers.h into my header and when I compile I get a lot of strange errors like that :

sciwrappers.h:34: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘->’ token

All the lines with a glib type (gchar, gboolean, ...) have that error and I really don't see what it means... I checked the file and it seems correct to me. I also tried to add the include of glib.h but that does nothing.

Anyone see what appen ?

Yes, an include of glib.h seems actually missing, it should probably[1] be added. Well, after a small research, it is quite more complex. First, to have ScintillaObject to be defined in ScintillaWidget.h, to have to define PLAT_GTK to a value passing the #if preprocessor directive (e.g. 1). But ScintillaWidget.h misses to include gtk/gtk.h too. Then if you would include sciwrappers, for now you have to do: #define PLAT_GTK 1 #include <gtk/gtk.h> /* #include <glib.h> // usless as GTK depends on GLib and includes it */ #include <sciwrappers.h> But all in all, I'm not sure it is an intentional behaviour, I'll let a Geany developer go deeper in this.

But AFAIR you should use the new geanyplugin.h header in place of all other Geany header, with which to haven't any problem, then it fixes the problem for your use.

Regards, Colomban

[1] not sure of the policy of inludes in header in Geany code, way for Enrico, Nick or Frank. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqIVQQACgkQyqbACDEjVWhxjgCgjG/S/nLBw/F5otkzbUu7Fa9G xHMAnRp3mbVdpqln7C7Y68GEVrZt2zsS =hPgN -----END PGP SIGNATURE-----

---

Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Hello Enrico,

Thanks for replying. I didn't understand how it was working, since I directly open the sciwrappers.h file :-) It's all right now !

Regards, Cedric

2009/8/16 Enrico Tröger enrico.troeger@uvena.de

On Sun, 16 Aug 2009 21:11:51 +0200, Cédric wrote:

Hi,

answering your mails is hard the way you quote.

About your initial question abut including sciwrappers.h: the order of header includes is important, I think I already told you that in another thread. First include geany.h, then other Geany includes like document.c or sciwrappers.h, then include pluginmacros.h and geanyfunctions.h. You can't include headers randomly. See other plugins how they do it.

All stuff Colomban explained with PLAT_GTK and ScintillaObject declaration is not true as long as you include geany.h. That does all the necessary stuff for you. Check this file to get a clue.

And last but not least, since Geany 0.18 it's recommended to *only* include geanyplugin.h which does everything for you. But obviously you need Geany 0.18 for this and you need to adjust the required plugin API version in your plugin accordingly (that is set it to 150).

...

Okay thanks it compiles now :) But I still have a problem with a function which is into sciwrapper.h. When I launch geany and open the Can't load plugin: /usr/local/lib/geany/pretty-print.so: undefined symbol: sci_scroll_columns

sci_scroll_columns() is not part of the plugin API. If you can't find a function in the plugin API docs (http://www.geany.org/manual/reference/), you can't use it in your plugin. Either we add the function to the API but then you would require Geany 0.19 which is not yet released or you simply call the corresponding Scintilla message directly:

scintilla_send_message(sci, SCI_LINESCROLL, columns, 0)

Regards, Enrico

-- Get my GPG key from http://www.uvena.de/pub.asc

---

Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

On Sun, 16 Aug 2009 21:50:14 +0200, Thomas wrote:

Enrico Tröger schrieb:

...

On Sun, 16 Aug 2009 21:11:51 +0200, Cédric wrote:

Hi,

answering your mails is hard the way you quote.

About your initial question abut including sciwrappers.h: the order of header includes is important, I think I already told you that in another thread. First include geany.h, then other Geany includes like document.c or sciwrappers.h, then include pluginmacros.h and geanyfunctions.h. You can't include headers randomly. See other plugins how they do it.

I think this situation is suboptimal.

A way to work around at least is to add some #warning (or even #error), like

#ifndef GEANY_H #warning geany.h needs to be included before this file #endif

in sciwrappers.h for example.

We could do this but to get any sense of it we would do this in all public header files. Anyway, the plugin howto clearly says to use "geanyplugin.h" as single header include to avoid all such problems and I don't see any reason why not to do this. All you need is Geany 0.18.

Regards, Enrico

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi,

Enrico Tröger wrote:

About your initial question abut including sciwrappers.h: the order of header includes is important, I think I already told you that in another thread. First include geany.h, then other Geany includes like document.c or sciwrappers.h, then include pluginmacros.h and geanyfunctions.h. You can't include headers randomly. See other plugins how they do it.

All stuff Colomban explained with PLAT_GTK and ScintillaObject declaration is not true as long as you include geany.h. That does all the necessary stuff for you. Check this file to get a clue.

Just for my self curiousity about including order: why does it is required? I'm a partisan of the "include all you need, but no more" style, meaning that if I use a symbol, I have to include what defines it. e.g. for sciwrappers.h, I would include glib.h as it uses GLib types and define or include something that defines PLAT_GTK. I don't see any reason why not doing this, and I think it is better for each code part to be self-sufficient. Then the question: why it is done this way?

Thomas Martitz wrote:

A way to work around at least is to add some #warning (or even #error), like […]

#warning is a GCC (and perhaps others) extension, prefer #error for general cases ;)

Regards, Colomban

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Enrico Tröger wrote:

On Sun, 16 Aug 2009 22:08:00 +0200, Colomban wrote:

...

Just for my self curiousity about including order: why does it is required? I'm a partisan of the "include all you need, but no more" style, meaning that if I use a symbol, I have to include what defines it. e.g. for sciwrappers.h, I would include glib.h as it uses GLib types and define or include something that defines PLAT_GTK. I don't see any

You want to define things in your code again just to not include a header file?

No, but include the header defining them rather than needing the user to do so.

Single header includes are generally more easy and pretty common. E.g. GTK and GLib do require them since some time. In case of Geany, the overhead which raises by including a bit more than strictly necessary is really really small compared what overhead GTK brings in and so I really don't see any real reason. At least, IMO, the advantages for maintainers and plugin authors are much bigger.

I think I've been misunderstood quite a bit, sorry. No, I'm not against single-header policy, even if I think is cleaner to include only what I need when possible, but for a library (like GTK+), for sure I see the point of one single global header including all others. What I'm against, and what I don't understand, is "missing" includes in headers. I think it is a bit cleaner, easier and less error prone to have each header to be self-sufficient in regard of the including code, i.e. if sciwrappers.h needs geany.h, I think sciwrappers.h should include geany.h itself rather than needing to be included before by the including code. In other words, when I include a header, I care about functionalities it provides (declares), and I won't care about how it is implemented (then what it needs). For example, if I would use foo, I include foo.h, and I wouldn't have to care that the the public Foo structure have a member of the Bar type (defined in bar.h) that I don't use. Hum, I think I should have said "include all you need" without the "but no more" that was only here to say that I wouldn't include *directly* (no care about it is included by what I include) headers I don't need.

But yes, single headers fixes this problem since they include all what it is needed, but I sill think each header should include all what it needs too.

Regards, Colomban

Enrico Tröger schrieb:

On Sun, 16 Aug 2009 23:14:19 +0200, Colomban wrote:

...

I think I've been misunderstood quite a bit, sorry. No, I'm not against single-header policy, even if I think is cleaner to include only what I need when possible, but for a library (like GTK+), for sure I see the point of one single global header including all others. What I'm against, and what I don't understand, is "missing" includes in headers. I think it is a bit cleaner, easier and less error prone to have each header to be self-sufficient in regard of the including code, i.e. if sciwrappers.h needs geany.h, I think sciwrappers.h should include geany.h itself rather than needing to be included before by the including code. In other words, when I include a header, I care about functionalities it provides (declares), and I won't care about how it is implemented (then what it needs). For example, if I would use foo, I include foo.h, and I wouldn't have to care that the the public Foo structure have a member of the Bar type (defined in bar.h) that I don't use. Hum, I think I should have said "include all you need" without the "but no more" that was only here to say that I wouldn't include *directly* (no care about it is included by what I include) headers I don't need.

I'm totally with you here, wholeheartedly.

Ok, I got it now. Sorry. Still in Geany itself, first include geany.h, for any plugins just include geanyplugin.h and you are done. Yes, we could change the code so that headers are safer to be included more randomly but who does it?

I do. Because I don't care about the squence. I include the header as I need them, not as the header require it.

Regarding Geany's core code, basically, it is just geany.h which you should include at first. Other headers' order doesn't matter much.

In my first post in this thread I said the order of the includes is important, that is only partly true and with the new geanyplugin.h it isn't true anymore at all because you have only one include and so the order is not important, haha.

But assuming one doesn't use geanyplugin.h and instead includes various headers, the order is important in that way that you:

• first include geany.h
• then include other core Geany header as well as Scintilla and

tagmanager headers if necessary

• finally include pluginmacros.h and geanyfunctions.h

Again, now, just include geanyfunction.h and we don't need to discuss this further.

Btw, say big thanks to Nick who brought us this great header.

Regards, Enrico

I just don't sure what the reason against fine headers which are complete themselves is. IMO, that's good practice.