TextAdept module on Windows: don't pop up cmd

[Kelet]

Hello,

The command line which pops up due to io.popen on Windows sucks, because you lose focus for a short period of time. I've seen an acknowledgement of this but don't see a bug for it.

@stevedonovan has a Lua module called winapi which may be able to help. The DLL is ~25kb, and perhaps we could distribute it with DCD's TA module. I believe spawn_process (and perhaps the Lua code for execute) may be of help.

I will investigate the implementation in the future.

[Hackerpilot]

The latest nightly build of Textadept has this feature implemented. Try the nightly and see how it works for you.

[Kelet]

Unfortunately, the nightly build breaks code. The new io.popen returns a table that has a few functions, but no write, flush, etc. You can see this in lines 15-28 of file_io.lua in changeset 1640. A more low-level but closer representation of io.popen would be

process, file = winapi.spawn_process(cmd)

This provides something that attempts to emulate a lua file handle -- the table we have now is a higher-level abstraction; however, file is still not a real Lua file object, according to winapi's documentation:

The file object is unfortunately not a Lua file object, since it is not possible to portably re-use the existing Lua implementation without copying large chunks of liolib.c into this library. So @{File:read} grabs what's available, unbuffered. But I feel that it's easy enough for Lua code to parse the result into separate lines, if needed.

Having a @{File:write} method means that, yes, you can capture an interactive process, send it commands and read the result. The caveat is that this process must not buffer standard output.

In my experiments, I haven't been able to get File:write to work even with the file object from winapi.spawn_process. I think that Mitchell should implement a new function rather than try to replace io.popen, because I don't think it would be practical to attempt to fully emulate it. I think that winapi.spawn_process might be what we need to use, but write is null for me and not a function, even though @stevedonovan clearly uses it in his README.md[1]. I'll try to look into it more if I find the time, but I have finals coming up in the next few weeks.

[1]

> proc,file = winapi.spawn_process [[python -i]]
> = file:read()
Python 2.6.2c1 (r262c1:71369, Apr  7 2009, 18:44:00) [MSC v.1500 32 bit (Intel)]
 on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
> file:write '40+2\n'
> = file:read()
42
>>>

[Kelet]

I'll send a link to my comment to Mitchell, as he may be the more relevant party here.

[Kelet]

Mitchell sent me an e-mail stating that the problem may have been fixed in the latest nightly build of TextAdept. When I get some time next week I'll see if I can confirm. Until then, anyone can feel free to try.

[Hackerpilot]

I just grabbed a nightly build and it's still broken.

[Kelet]

I can reproduce that it still does not work. I'll notify Mitchell and when I have some more time available I'll try to pinpoint what the problem is now.

[Kelet]

I talked to Mitchell and apparently the nightly build was not uploaded because of an error stopping compilation. The current nightly build has the proposed fix.

It still does not work, but it comes closer. Basically, the file is opened when it should be, but is only populated with the output of dcd-client when TextAdept is exited. I'm not exactly sure why that is, however.

[Hackerpilot]

This is fixed with the https://github.com/Hackerpilot/textadept-d plugin.