Hello,
I hacked up a document message to inform the user about this new
behavior, see attached screenshot.
However, as we entered string freeze, I don't suppose a new dialog like
this is acceptable at this point? What else can we do for *this* release?
Best regards
_
On 26 June 2015 at 11:11, Matthew Brush wrote:
> On 2015-06-20 08:12 PM, Matthew Brush wrote:
>>
>> Hi All,
>>
>> I just noticed that the new spawn code exposes almost every single bit
>> of API possible. Do we really want to do that, or should we limit it
>> only to what is currently needed by an
On 2015-06-20 08:12 PM, Matthew Brush wrote:
Hi All,
I just noticed that the new spawn code exposes almost every single bit
of API possible. Do we really want to do that, or should we limit it
only to what is currently needed by any plugins? A quick survey of
Geany-Plugins shows no usage of any
Hi Dimitar,
I'm now totally confused, so let me ask the important question directly:
A user is entering a command into Geany, if the command is going to be
run by spawn_* will they enter it the same way as they would if the
command is going to be run by g_spawn*? In all versions,
sync/async/pipe
On 24.6.2015 г. 03:12, Lex Trotman wrote:
On 24 June 2015 at 10:06, Colomban Wendling wrote:
Le 24/06/2015 01:57, Lex Trotman a écrit :
Colomban,
Correct me if I'm wrong, but despite my loudly voiced misgivings :)
doesn't the spawn_* series do command quoting and g_spawn* not?
No. It uses q
On 24.6.2015 г. 02:05, Colomban Wendling wrote:
IMO, spawn_with_callbacks() is *the* key API from spawn, what makes it
great.
It is, indeed.
spawn_async_with_pipes() can be nice, but most people probably shouldn't
use them as they have same IO trickery most IO layers have, where you
have to
On 24.6.2015 г. 01:18, Matthew Brush wrote:
On 2015-06-23 09:04 AM, Dimitar Zhekov wrote:
[...]
From you're previous email you mentioned the stuff checked with [x] below:
[x] spawn_kill_process()
[x] spawn_with_callbacks()
[x] spawn_write_data()
[x] SpawnFlags
[x] SpawnReadFunc
[x] SpawnWrit
