Hi,
I have developed the EditorConfig plugin for Geany https://github.com/editorconfig/editorconfig-geany.
""" EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of *a file format* for defining coding styles and a collection of *text editor plugins* that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readibly and they work nicely with version control systems. Website here http://editorconfig.org """
However, I am confused how to publish this plugin.
First, http://plugins.geany.org is a place for plugin list. But are the third party plugins allowed here? All the pages seem working for the plugins here: https://github.com/geany/geany-plugins including the download page, installation page.
Whatever the answer is, can I put my plugin in https://github.com/geany/geany-plugins ? This repository seems better maintained than mine.
The second problem is that, how should I bundle a third party C library with my plugin?
Thank you!
Hong
On Jul 7, 2012, at 13:39, Hong Xu dev@hong.me wrote:
Hi,
I have developed the EditorConfig plugin for Geany https://github.com/editorconfig/editorconfig-geany.
""" EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of *a file format* for defining coding styles and a collection of *text editor plugins* that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readibly and they work nicely with version control systems. Website here http://editorconfig.org """
However, I am confused how to publish this plugin.
First, http://plugins.geany.org is a place for plugin list. But are the third party plugins allowed here? All the pages seem working for the plugins here: https://github.com/geany/geany-plugins including the download page, installation page.
Whatever the answer is, can I put my plugin in https://github.com/geany/geany-plugins ? This repository seems better maintained than mine.
The second problem is that, how should I bundle a third party C library with my plugin?
Thank you!
Would any one offer some help on this? Thank you!
Hong
On 10 July 2012 14:07, Hong Xu dev@hong.me wrote:
On Jul 7, 2012, at 13:39, Hong Xu dev@hong.me wrote:
Hi,
I have developed the EditorConfig plugin for Geany https://github.com/editorconfig/editorconfig-geany.
""" EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of *a file format* for defining coding styles and a collection of *text editor plugins* that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readibly and they work nicely with version control systems. Website here http://editorconfig.org """
However, I am confused how to publish this plugin.
First, http://plugins.geany.org is a place for plugin list. But are the third party plugins allowed here? All the pages seem working for the plugins here: https://github.com/geany/geany-plugins including the download page, installation page.
Whatever the answer is, can I put my plugin in https://github.com/geany/geany-plugins ? This repository seems better maintained than mine.
The second problem is that, how should I bundle a third party C library with my plugin?
Thank you!
Would any one offer some help on this? Thank you!
Patience, the plugin project is trying to get a release out. I am sure they will help you as soon as they can.
Cheers Lex
Hong _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 12-07-06 10:39 PM, Hong Xu wrote:
Hi,
I have developed the EditorConfig plugin for Geany https://github.com/editorconfig/editorconfig-geany.
""" EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of *a file format* for defining coding styles and a collection of *text editor plugins* that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readibly and they work nicely with version control systems. Website here http://editorconfig.org """
However, I am confused how to publish this plugin.
First, http://plugins.geany.org is a place for plugin list. But are the third party plugins allowed here? All the pages seem working for the plugins here: https://github.com/geany/geany-plugins including the download page, installation page.
Whatever the answer is, can I put my plugin in https://github.com/geany/geany-plugins ? This repository seems better maintained than mine.
I would assume it's OK, but you'll need to "be approved" by the Geany-Plugins maintainer. Usually if you have a useful plugin that's well coded enough, you just ask like you did and work with the maintainer and other devs to integrate the plugin. You happen to have asked right as the maintainer and other devs are preparing for a majour release, so it kind of explains the silence to your question.
The second problem is that, how should I bundle a third party C library with my plugin?
If the library is readily available on the target platforms, you depend on it using the build system and link it in (many plugins do this). If it's really obscure or not packaged anywhere then you could just compile its sources into your plugins'. The latter is what the Devhelp plugin does for libdevhelp since it's not packaged for GTK+2 anymore on the target platforms, but it's still quite a stupid thing to do.
P.S. If you don't get any further with adding your plugin to the project, wait until you see the release announcement for Geany-Plugins here then you will know when people will be freed up more to help you.
Cheers, Matthew Brush
On 07/10/2012 01:50 PM, Matthew Brush wrote:
On 12-07-06 10:39 PM, Hong Xu wrote:
Hi,
I have developed the EditorConfig plugin for Geany https://github.com/editorconfig/editorconfig-geany.
""" EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of *a file format* for defining coding styles and a collection of *text editor plugins* that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readibly and they work nicely with version control systems. Website here http://editorconfig.org """
However, I am confused how to publish this plugin.
First, http://plugins.geany.org is a place for plugin list. But are the third party plugins allowed here? All the pages seem working for the plugins here: https://github.com/geany/geany-plugins including the download page, installation page.
Whatever the answer is, can I put my plugin in https://github.com/geany/geany-plugins ? This repository seems better maintained than mine.
I would assume it's OK, but you'll need to "be approved" by the Geany-Plugins maintainer. Usually if you have a useful plugin that's well coded enough, you just ask like you did and work with the maintainer and other devs to integrate the plugin. You happen to have asked right as the maintainer and other devs are preparing for a majour release, so it kind of explains the silence to your question.
Ok, thanks!
The second problem is that, how should I bundle a third party C library with my plugin?
If the library is readily available on the target platforms, you depend on it using the build system and link it in (many plugins do this). If it's really obscure or not packaged anywhere then you could just compile its sources into your plugins'. The latter is what the Devhelp plugin does for libdevhelp since it's not packaged for GTK+2 anymore on the target platforms, but it's still quite a stupid thing to do.
Yes, this seems not reasonable, but I still need to do so. The library isn't available anywhere on the target system.
P.S. If you don't get any further with adding your plugin to the project, wait until you see the release announcement for Geany-Plugins here then you will know when people will be freed up more to help you.
Alright. I'll be waiting :)
Hong
On Sat, 2012-07-07 at 13:39 +0800, Hong Xu wrote:
First, http://plugins.geany.org is a place for plugin list. But are the third party plugins allowed here? All the pages seem working for the plugins here: https://github.com/geany/geany-plugins including the download page, installation page.
We already had another section for "Thirdparty plugins" in the navigation. I removed the section because every of those three plugins mentioned there were outdated or moved into the Geany-Plugins project itself and that section thus wasn't necessary anymore. :)
It would be no big deal to introduce it again if you like. You can just open another pull request for the plugins.geany.org website and I'll have a look on it as soon as I find the time to do that. :)
Regards, Dominic
On Sat, 2012-07-14 at 20:12 +0200, Dominic Hopf wrote:
It would be no big deal to introduce it again if you like. You can just open another pull request for the plugins.geany.org website and I'll have a look on it as soon as I find the time to do that. :)
If you're going to add your plugin to the Geany-Plugins project as well, be advised I have another mail from Matthew flagged as "TODO" for the plugins.geany.org website.
At present it is generating the navigation from a tagged release in Git. I like Matthews idea to add plugins from the master branch when they don't exist in the tagged release yet and add a hint to the generated page that that specific plugin is under development. Only thing missing is the implementation... :)
Regards, Dominic
On 07/15/2012 02:12 AM, Dominic Hopf wrote:
On Sat, 2012-07-07 at 13:39 +0800, Hong Xu wrote:
First, http://plugins.geany.org is a place for plugin list. But are the third party plugins allowed here? All the pages seem working for the plugins here: https://github.com/geany/geany-plugins including the download page, installation page.
We already had another section for "Thirdparty plugins" in the navigation. I removed the section because every of those three plugins mentioned there were outdated or moved into the Geany-Plugins project itself and that section thus wasn't necessary anymore. :)
It would be no big deal to introduce it again if you like. You can just open another pull request for the plugins.geany.org website and I'll have a look on it as soon as I find the time to do that. :)
Thank you. I'll make a pull request first, and then try to move it to geany-plugins project :)
And, BTW, why geany-plugins project doesn't use a submodule for each plugin? Not all people need to clone the whole repository, and as it is separated to submodules, the permission control can be better for developers.
Hong
On Sun, 15 Jul 2012 09:27:46 +0800 Hong Xu dev@hong.me wrote:
And, BTW, why geany-plugins project doesn't use a submodule for each plugin? Not all people need to clone the whole repository, and as it is separated to submodules, the permission control can be better for developers.
IIRc this was under discussion in past but was dismissed due to adding complexity and little overall understanding of this. However, I don't think cloning the repository is this much traffic. Also a goal was to have plugins and its patches being reviewed before entering master to enforce a minimum on quality. This also includes some fire-and-forget-plugins of some developers as you can see from MAINTAINERS files there are a lot of plugins out of maintenance.
Cheers, Frank
On 07/15/2012 03:40 PM, Frank Lanitz wrote:
On Sun, 15 Jul 2012 09:27:46 +0800 Hong Xu dev@hong.me wrote:
And, BTW, why geany-plugins project doesn't use a submodule for each plugin? Not all people need to clone the whole repository, and as it is separated to submodules, the permission control can be better for developers.
IIRc this was under discussion in past but was dismissed due to adding complexity and little overall understanding of this. However, I don't think cloning the repository is this much traffic. Also a goal was to have plugins and its patches being reviewed before entering master to enforce a minimum on quality. This also includes some fire-and-forget-plugins of some developers as you can see from MAINTAINERS files there are a lot of plugins out of maintenance.
Thanks. However, I have to make a pull request for any trivial changes in this way. Do you think this is unnecessary?
In you mind, is there any advantages for geany plugins in this repo other than other places?
Thank you, Hong
On 07/15/2012 07:01 PM, Hong Xu wrote:
On 07/15/2012 03:40 PM, Frank Lanitz wrote:
On Sun, 15 Jul 2012 09:27:46 +0800 Hong Xu dev@hong.me wrote:
And, BTW, why geany-plugins project doesn't use a submodule for each plugin? Not all people need to clone the whole repository, and as it is separated to submodules, the permission control can be better for developers.
IIRc this was under discussion in past but was dismissed due to adding complexity and little overall understanding of this. However, I don't think cloning the repository is this much traffic. Also a goal was to have plugins and its patches being reviewed before entering master to enforce a minimum on quality. This also includes some fire-and-forget-plugins of some developers as you can see from MAINTAINERS files there are a lot of plugins out of maintenance.
Thanks. However, I have to make a pull request for any trivial changes in this way. Do you think this is unnecessary?
In you mind, is there any advantages for geany plugins in this repo other than other places?
Sorry, any *other* besides the quality enforcement?
Hong
On 15 July 2012 21:03, Hong Xu dev@hong.me wrote:
On 07/15/2012 07:01 PM, Hong Xu wrote:
On 07/15/2012 03:40 PM, Frank Lanitz wrote:
On Sun, 15 Jul 2012 09:27:46 +0800 Hong Xu dev@hong.me wrote:
And, BTW, why geany-plugins project doesn't use a submodule for each plugin? Not all people need to clone the whole repository, and as it is separated to submodules, the permission control can be better for developers.
IIRc this was under discussion in past but was dismissed due to adding complexity and little overall understanding of this. However, I don't think cloning the repository is this much traffic. Also a goal was to have plugins and its patches being reviewed before entering master to enforce a minimum on quality. This also includes some fire-and-forget-plugins of some developers as you can see from MAINTAINERS files there are a lot of plugins out of maintenance.
Thanks. However, I have to make a pull request for any trivial changes in this way. Do you think this is unnecessary?
In you mind, is there any advantages for geany plugins in this repo other than other places?
Sorry, any *other* besides the quality enforcement?
Well, of course the geany-plugins is packaged for at least some distros, in particular debian and ubuntu. That will of course get greater exposure, and maybe contributions, and also maybe bug reports :)
BTW you mentioned a third party library, but you didn't say what library. It would of course have to have a suitable license to allow it to be included.
Cheers Lex
Hong
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 15 Jul 2012 21:56:32 +1000 Lex Trotman elextr@gmail.com wrote:
BTW you mentioned a third party library, but you didn't say what library. It would of course have to have a suitable license to allow it to be included.
Yes. I missed that too. Most plugins are GPL2+ so it needs to be also GPL2+... BSD should also be fine in most cases. But LGPL could be problematic.
On 2012/7/15 20:28, Frank Lanitz wrote:
On Sun, 15 Jul 2012 21:56:32 +1000 Lex Trotman elextr@gmail.com wrote:
BTW you mentioned a third party library, but you didn't say what library. It would of course have to have a suitable license to allow it to be included.
Yes. I missed that too. Most plugins are GPL2+ so it needs to be also GPL2+... BSD should also be fine in most cases. But LGPL could be problematic.
I prefer Simplified BSD License for this plugin. What do you mean it should be fine for "most" cases? Could you explain more?
Thanks, Hong
Am 16.07.2012 16:41, schrieb Hong Xu:
On 2012/7/15 20:28, Frank Lanitz wrote:
On Sun, 15 Jul 2012 21:56:32 +1000 Lex Trotman elextr@gmail.com wrote:
BTW you mentioned a third party library, but you didn't say what library. It would of course have to have a suitable license to allow it to be included.
Yes. I missed that too. Most plugins are GPL2+ so it needs to be also GPL2+... BSD should also be fine in most cases. But LGPL could be problematic.
I prefer Simplified BSD License for this plugin. What do you mean it should be fine for "most" cases? Could you explain more?
The 2-clause BSD is always fun. As is LGPLv2+.
Best regards.
Am 16.07.2012 16:58, schrieb Thomas Martitz:
Am 16.07.2012 16:41, schrieb Hong Xu:
On 2012/7/15 20:28, Frank Lanitz wrote:
On Sun, 15 Jul 2012 21:56:32 +1000 Lex Trotman elextr@gmail.com wrote:
BTW you mentioned a third party library, but you didn't say what library. It would of course have to have a suitable license to allow it to be included.
Yes. I missed that too. Most plugins are GPL2+ so it needs to be also GPL2+... BSD should also be fine in most cases. But LGPL could be problematic.
I prefer Simplified BSD License for this plugin. What do you mean it should be fine for "most" cases? Could you explain more?
The 2-clause BSD is always fun. As is LGPLv2+.
s/fun/fine/ :)
On Mon, 16 Jul 2012 16:59:12 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 16.07.2012 16:58, schrieb Thomas Martitz:
Am 16.07.2012 16:41, schrieb Hong Xu:
On 2012/7/15 20:28, Frank Lanitz wrote:
On Sun, 15 Jul 2012 21:56:32 +1000 Lex Trotman elextr@gmail.com wrote:
BTW you mentioned a third party library, but you didn't say what library. It would of course have to have a suitable license to allow it to be included.
Yes. I missed that too. Most plugins are GPL2+ so it needs to be also GPL2+... BSD should also be fine in most cases. But LGPL could be problematic.
I prefer Simplified BSD License for this plugin. What do you mean it should be fine for "most" cases? Could you explain more?
The 2-clause BSD is always fun. As is LGPLv2+.
s/fun/fine/ :)
Rethinking about ..... well, you might are correct. In terms of distribution as we most likely will do, LPGL should also be fine. Sorry - my fault. In terms of BSD I'm thinking about some special parts e.g. calling author's names inside credits I saw in past. But should not be apply able on our case....
Cheers, Frank
On 2012/7/15 19:56, Lex Trotman wrote:
On 15 July 2012 21:03, Hong Xu dev@hong.me wrote:
On 07/15/2012 07:01 PM, Hong Xu wrote:
On 07/15/2012 03:40 PM, Frank Lanitz wrote:
On Sun, 15 Jul 2012 09:27:46 +0800 Hong Xu dev@hong.me wrote:
And, BTW, why geany-plugins project doesn't use a submodule for each plugin? Not all people need to clone the whole repository, and as it is separated to submodules, the permission control can be better for developers.
IIRc this was under discussion in past but was dismissed due to adding complexity and little overall understanding of this. However, I don't think cloning the repository is this much traffic. Also a goal was to have plugins and its patches being reviewed before entering master to enforce a minimum on quality. This also includes some fire-and-forget-plugins of some developers as you can see from MAINTAINERS files there are a lot of plugins out of maintenance.
Thanks. However, I have to make a pull request for any trivial changes in this way. Do you think this is unnecessary?
In you mind, is there any advantages for geany plugins in this repo other than other places?
Sorry, any *other* besides the quality enforcement?
Well, of course the geany-plugins is packaged for at least some distros, in particular debian and ubuntu. That will of course get greater exposure, and maybe contributions, and also maybe bug reports :)
BTW you mentioned a third party library, but you didn't say what library. It would of course have to have a suitable license to allow it to be included.
The library is here: https://github.com/editorconfig/editorconfig-core
It is released under Simplified BSD License. So I believe this is not an issue.
Hong
On Sun, 15 Jul 2012 19:01:53 +0800 Hong Xu dev@hong.me wrote:
On 07/15/2012 03:40 PM, Frank Lanitz wrote:
On Sun, 15 Jul 2012 09:27:46 +0800 Hong Xu dev@hong.me wrote:
And, BTW, why geany-plugins project doesn't use a submodule for each plugin? Not all people need to clone the whole repository, and as it is separated to submodules, the permission control can be better for developers.
IIRc this was under discussion in past but was dismissed due to adding complexity and little overall understanding of this. However, I don't think cloning the repository is this much traffic. Also a goal was to have plugins and its patches being reviewed before entering master to enforce a minimum on quality. This also includes some fire-and-forget-plugins of some developers as you can see from MAINTAINERS files there are a lot of plugins out of maintenance.
Thanks. However, I have to make a pull request for any trivial changes in this way. Do you think this is unnecessary?
We are still in finding a good flow on this as I agree its not optimal.
In you mind, is there any advantages for geany plugins in this repo other than other places?
Well... You don't need to care about releases, some translations topics and some minor changes. Also in terms of visibility. But I don't think its really needed for every plugin to be part of, no.
Cheers, Frank
Am 15.07.2012 14:26, schrieb Frank Lanitz:
On Sun, 15 Jul 2012 19:01:53 +0800 Hong Xu dev@hong.me wrote:
On 07/15/2012 03:40 PM, Frank Lanitz wrote:
On Sun, 15 Jul 2012 09:27:46 +0800 Hong Xu dev@hong.me wrote:
And, BTW, why geany-plugins project doesn't use a submodule for each plugin? Not all people need to clone the whole repository, and as it is separated to submodules, the permission control can be better for developers.
IIRc this was under discussion in past but was dismissed due to adding complexity and little overall understanding of this. However, I don't think cloning the repository is this much traffic. Also a goal was to have plugins and its patches being reviewed before entering master to enforce a minimum on quality. This also includes some fire-and-forget-plugins of some developers as you can see from MAINTAINERS files there are a lot of plugins out of maintenance.
Thanks. However, I have to make a pull request for any trivial changes in this way. Do you think this is unnecessary?
We are still in finding a good flow on this as I agree its not optimal.
Most of the time changes are not actually trivial. Also multiple small and trivial changes can be submitted as a single pull request.
Anyway this is the linux kernel dev model and it works good (for some projects) even if tiny changes need to go through the chain as well.
Best regards.
On 2012/7/15 21:21, Thomas Martitz wrote:
Am 15.07.2012 14:26, schrieb Frank Lanitz:
On Sun, 15 Jul 2012 19:01:53 +0800 Hong Xu dev@hong.me wrote:
On 07/15/2012 03:40 PM, Frank Lanitz wrote:
On Sun, 15 Jul 2012 09:27:46 +0800 Hong Xu dev@hong.me wrote:
And, BTW, why geany-plugins project doesn't use a submodule for each plugin? Not all people need to clone the whole repository, and as it is separated to submodules, the permission control can be better for developers.
IIRc this was under discussion in past but was dismissed due to adding complexity and little overall understanding of this. However, I don't think cloning the repository is this much traffic. Also a goal was to have plugins and its patches being reviewed before entering master to enforce a minimum on quality. This also includes some fire-and-forget-plugins of some developers as you can see from MAINTAINERS files there are a lot of plugins out of maintenance.
Thanks. However, I have to make a pull request for any trivial changes in this way. Do you think this is unnecessary?
We are still in finding a good flow on this as I agree its not optimal.
Most of the time changes are not actually trivial. Also multiple small and trivial changes can be submitted as a single pull request.
Anyway this is the linux kernel dev model and it works good (for some projects) even if tiny changes need to go through the chain as well.
OK, that should be fine.
Hong
On Sat, 07 Jul 2012 13:39:56 +0800 Hong Xu dev@hong.me wrote:
Whatever the answer is, can I put my plugin in https://github.com/geany/geany-plugins ? This repository seems better maintained than mine.
I didn't have a look onto you code by now but in general you can add you plugin also to geany-plugins project. I'd prefer you to having you own fork of plugins and sending pull request against geany/geany-plguins/master
The second problem is that, how should I bundle a third party C library with my plugin?
I think Matthew answered here very well. It really depends on how common this library is or if you are patching it in some kind. Well... I don't like shipping to much libraries with one plugin as there is always an question of updates in terms of a security fault etc. Also this might could cause ending up in typical Windows scenario where you are might having GTK installed about 1000 times - each GTK serving its own application. So: if the library is typical packaged for target platforms or if its available via a common way (e.g. ppa on Ubuntu, some of the rpm-pages for SuSE or Fedora/RH/SL) and you don't have any patches inside I wouldn't deliver it with the plugin but depend on it.
Cheers, Frank
On 2012/7/15 15:49, Frank Lanitz wrote:
On Sat, 07 Jul 2012 13:39:56 +0800 Hong Xu dev@hong.me wrote:
Whatever the answer is, can I put my plugin in https://github.com/geany/geany-plugins ? This repository seems better maintained than mine.
I didn't have a look onto you code by now but in general you can add you plugin also to geany-plugins project. I'd prefer you to having you own fork of plugins and sending pull request against geany/geany-plguins/master
The second problem is that, how should I bundle a third party C library with my plugin?
I think Matthew answered here very well. It really depends on how common this library is or if you are patching it in some kind. Well... I don't like shipping to much libraries with one plugin as there is always an question of updates in terms of a security fault etc. Also this might could cause ending up in typical Windows scenario where you are might having GTK installed about 1000 times - each GTK serving its own application. So: if the library is typical packaged for target platforms or if its available via a common way (e.g. ppa on Ubuntu, some of the rpm-pages for SuSE or Fedora/RH/SL) and you don't have any patches inside I wouldn't deliver it with the plugin but depend on it.
Currently, the library is not commonly distributed under common distributions. The library URL is: https://github.com/editorconfig/editorconfig-core
There's a problem here: the library build system is based on CMake, while the geany-plugins project supports both autotools and waf. If I want to include the source in my code, I would probably have to reproduce the cmake build system using autotools. Do you have any suggestions handling a CMake third party library in geany-plugins? And do I also need to support BOTH the two build systems?
Hong
On Mon, 16 Jul 2012 23:13:55 +0800 Hong Xu dev@hong.me wrote:
On 2012/7/15 15:49, Frank Lanitz wrote:
On Sat, 07 Jul 2012 13:39:56 +0800 Hong Xu dev@hong.me wrote:
Whatever the answer is, can I put my plugin in https://github.com/geany/geany-plugins ? This repository seems better maintained than mine.
I didn't have a look onto you code by now but in general you can add you plugin also to geany-plugins project. I'd prefer you to having you own fork of plugins and sending pull request against geany/geany-plguins/master
The second problem is that, how should I bundle a third party C library with my plugin?
I think Matthew answered here very well. It really depends on how common this library is or if you are patching it in some kind. Well... I don't like shipping to much libraries with one plugin as there is always an question of updates in terms of a security fault etc. Also this might could cause ending up in typical Windows scenario where you are might having GTK installed about 1000 times
- each GTK serving its own application. So: if the library is
typical packaged for target platforms or if its available via a common way (e.g. ppa on Ubuntu, some of the rpm-pages for SuSE or Fedora/RH/SL) and you don't have any patches inside I wouldn't deliver it with the plugin but depend on it.
Currently, the library is not commonly distributed under common distributions. The library URL is: https://github.com/editorconfig/editorconfig-core
Based on that I think including would be fine.
There's a problem here: the library build system is based on CMake, while the geany-plugins project supports both autotools and waf. If I want to include the source in my code, I would probably have to reproduce the cmake build system using autotools. Do you have any suggestions handling a CMake third party library in geany-plugins? And do I also need to support BOTH the two build systems?
Well.... please include it to autotools if ever possible. Even cmake might have some advantages (cannot say) I don't see any chance in terms of man power etc to have it also maintained.
Cheers, Frank