Hi,
As some of us know, I'm writing a completely new implementation of the spawning in Geany, to fix the issues under win~1, and to provide higher level interface, thus stopping the calling modules (build, search, ...) from doing "their own thing", for example tools.c using g_shell_parse_argv() even under win~1, which is a bug. You can have a look at the latest messages for [1].
My intention is to use this thread to discuss questionable spawning issues. So the first question is: should we _completely_ disable the console for win~1 console applications? If we do that, any stdout/err output not captured by a Geany pipe will be discarded. Under *nix, when Geany is not started from a terminal, such output normally goes to ~/.xsession-errors, which is somewhat useful.
I propose to always create the win~1 programs with a minimized, non-focused window. For console programs, the uncaptured output will go to the console, and will be lost when the console is auto closed by win~1, but that's better than nothing. Moreover, if a console program crashes, the console will remain on screen until you confirm the win~1 crash dialog.
[1] https://sourceforge.net/p/geany/bugs/943/
On 4 November 2013 00:29, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi,
As some of us know, I'm writing a completely new implementation of the spawning in Geany, to fix the issues under win~1, and to provide higher level interface, thus stopping the calling modules (build, search, ...) from doing "their own thing", for example tools.c using g_shell_parse_argv() even under win~1, which is a bug. You can have a look at the latest messages for [1].
Hi Dimitar,
Thank you in advance.
My intention is to use this thread to discuss questionable spawning issues. So the first question is: should we _completely_ disable the console for win~1 console applications? If we do that, any stdout/err output not captured by a Geany pipe will be discarded. Under *nix, when Geany is not started from a terminal, such output normally goes to ~/.xsession-errors, which is somewhat useful.
I propose to always create the win~1 programs with a minimized, non-focused window. For console programs, the uncaptured output will go to the console, and will be lost when the console is auto closed by win~1, but that's better than nothing. Moreover, if a console program crashes, the console will remain on screen until you confirm the win~1 crash dialog.
Though not a windows user, that sounds sensible to me, but will it work with execute keeping the console open until enter is pressed?
Cheers Lex
[1] https://sourceforge.net/p/geany/bugs/943/
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Mon, 4 Nov 2013 09:44:45 +1100 Lex Trotman elextr@gmail.com wrote:
I propose to always create the win~1 programs with a minimized, non-focused window. For console programs, the uncaptured output will go to the console, and will be lost when the console is auto closed by win~1, but that's better than nothing. Moreover, if a console program crashes, the console will remain on screen until you confirm the win~1 crash dialog.
Though not a windows user, that sounds sensible to me, but will it work with execute keeping the console open until enter is pressed?
No. Imagine if you need to close a minimized console for each tool (grep, gcc, ...) Geany launches. :)
So far, I don't plan to use the rewritten spawning for the build Execute commands, as they may contain > or >& redirection.
It seems that win~1 redirection is either all or none, so if you capture stdout, there will be no stderr in the console. However, our redirections are std{out,err}, std{in,out,err} or none (some calls to utils_spawn_sync).
Am 04.11.2013 19:04, schrieb Dimitar Zhekov:
On Mon, 4 Nov 2013 09:44:45 +1100 Lex Trotman elextr@gmail.com wrote:
I propose to always create the win~1 programs with a minimized, non-focused window. For console programs, the uncaptured output will go to the console, and will be lost when the console is auto closed by win~1, but that's better than nothing. Moreover, if a console program crashes, the console will remain on screen until you confirm the win~1 crash dialog.
Though not a windows user, that sounds sensible to me, but will it work with execute keeping the console open until enter is pressed?
No. Imagine if you need to close a minimized console for each tool (grep, gcc, ...) Geany launches. :)
Could you have some wrapper batch script like on Linux?
Best regards.
On Mon, 04 Nov 2013 21:33:36 +0100 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 04.11.2013 19:04, schrieb Dimitar Zhekov:
On Mon, 4 Nov 2013 09:44:45 +1100 Lex Trotman elextr@gmail.com wrote:
I propose to always create the win~1 programs with a minimized, non-focused window. [...]
Though not a windows user, that sounds sensible to me, but will it work with execute keeping the console open until enter is pressed?
No. Imagine if you need to close a minimized console for each tool (grep, gcc, ...) Geany launches. :)
Could you have some wrapper batch script like on Linux?
Yes, if you specify an interpreter .exe before the script, such as cmd /c my_gcc -Wall -c "%f" (win~1 CreatePropcess() starts binary executables only, and the .exe suffix is optional).