On 2015-06-22 10:18 AM, Dimitar Zhekov wrote:
On 21.6.2015 г. 20:39, Matthew Brush wrote:
On 2015-06-21 04:25 AM, Dimitar Zhekov wrote:
On 21.6.2015 г. 06:12, Matthew Brush wrote:
[...]
Spawn neither requires not uses anything from Geany (except i18n), and
does not change anything in Geany state, so it's functions are not
Yeah, it almost should be a "separate" library (at least like TM or
MIO). Personally I don't like the tendency of Geany's plugin API to be
getting bloated with stuff that has nothing to do with Geany or plugins,
but rather general purpose stuff making up for shortcomings in GLib, or
general-purpose convenience functions. But I think maybe this is a
conversation for another day.
+1 on that. Any generic purpose functions, not really dependent on
Geany, should be separated in a library, and used by Geany and the
plugins on equal basic. Perhaps in a next version...
Some reasons for the plugins to use the spawn API, in no particular order:
- supports native CL under Win~1 (not \-is-escape *nix parsing)
- does not spawn helper processes (creating a process is costly under
Win~1, though that's only notable for > several)
- handles locale arguments better (the former FiF locale error)
- may provide better security, depending on how glib starts processes
But I will not try to force the API on anybody, and do not want anyone
else to do so. If the reasons are not compelling, so be it.
I might try it with the code-format plugin eventually as it's currently
incredibly slow to do real-time formatting on Windows, because it spawns
clang-format _a lot_.
In the next plugins (after this release), Scope will require at least
WIF*, spawn_kill_process, SpawnFlags, SpawnReadFunc,
spawn_with_callbacks, SpawnWriteData and spawn_write_data.
It'll be good if 'debugger' uses them as well...
I figured there would be some use in at least Scope. Do you have any
problem if we make all the API private for now and then as you need it
in Scope (or any other plugins requesting it) we can export precisely
what is needed, at that time?
I want the next Scope to depend on Geany-1.25 stable-release. If the
functions are hidden now, it'll have to depend on Geany-git-date, which
I'd rather avoid...
We should make Colomban decide :) I get what you're saying but I also
feel uneasy about blanket exporting of APIs with no current users of it,
so we don't know exactly what really needs to be exported.
Cheers,
Matthew Brush
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
