[Geany-Devel] Spawn module API

Matthew Brush mbrush at xxxxx
Mon Jun 22 23:25:44 UTC 2015


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


More information about the Devel mailing list