GrepWithShell

[mMontu]

Following the same idea of :MakeWithShell and :LMakeWithShell, is it possible to create :GrepWithShell?

This would make possible to integrate :Fullscreen with ack.vim.

[xolox]

Anything is possible if the desire is there :-). The question is how much effort is involved and where do we stop? Vim has dozens of commands that invoke external programs and I have to draw the line somewhere. I haven't decided yet on which side of the line :GrepWithShell would fall :-).

I'm not familiar with ack.vim (haven't used it so far). If I add the :GrepWithShell command to the vim-shell plug-in, can you integrate it into ack.vim without my help? And would you do that by patching ack.vim or is it configurable enough to support this 'out of the box'?

[xolox]

I just browsed through the source code of ack.vim and I guess we would predefine g:ackprg so that ack.vim uses vim-shell without being aware of it. It wouldn't surprise me though if it's easier to write a Vim plug-in from scratch to run ack using vim-shell instead of defining a :GrepWithShell command that's compatible with ack.vim...

I'm wondering if it isn't possible to build a shell.exe program which runs the command given as a command line argument without opening a console window. I would have to build the shell.exe using the GUI subsystem, but otherwise I don't see any serious problems with the approach. Oh wait, I think GUI subsystem Windows executables don't have stdout/stderr streams :-(. I'll try to verify that.

[xolox]

Oh wait, I think GUI subsystem Windows executables don't have stdout/stderr streams :-(. I'll try to verify that.

Yup, the limitation is there. So the remaining options:

1. Patch the Vim for Windows source code module so it doesn't show console windows for console programs (not an option for anyone who doesn't have a build environment set up for Windows API development).
2. Define alternatives for all common ways to execute a non-interactive console program from Vim (a hell of a lot of work for me).
3. Convince all Vim plug-in authors out there to use xolox#misc#os#execute() (I'm pretty sure I won't be able to convince most of them :-).

Edit: If there was a way to intercept / hook into all attempts to run a child process, we could hide the console windows without having to patch Vim or convert hundreds of Vim plug-ins to use xolox#misc#os#execute() :-)

[xolox]

If there was a way to intercept / hook into all attempts to run a child process, we could hide the console windows without having to patch Vim or convert hundreds of Vim plug-ins to use xolox#misc#os#execute() :-)

I'm now reading about MS Detours (very expensive, have to sign NDAs, etc) and MHook (free and MIT licensed just like vim-shell :-D). I still don't know if this approach can work, but I'm willing to try. I might have some time this weekend.

[mMontu]

Certainly I could change ack.vim myself -- I just bothered you after checking how to do that. If you want to try out Ack, which is a great replacement for grep, you can find some info about it here..

After understanding the way you implemented :LMakeWithShell I was wondering if your intention would be to include most common ways of execute non-interactive console programs, with some kind of dictionary whose key would be the prefix of *WithShell commands.

But even if that is possible & easy to implement I agree that it would be a lot of work to patch some of others plugins to be compatible with those commands (e.g.: I was about to browse SingleCompile to check how to change it).

So I believe that is a very good idea to somehow intercept all attempts to run an external command (if it is possible :-D).

[mMontu]

Anything is possible if the desire is there :-).

After getting used to :Fullscreen is somewhat hard to live without it, and those console windows, that I almost doesn't noticed, turned to be so annoying that I actually get some desire ;-)

[mMontu]

From :h win32-vimrun:

Executing an external command is done indirectly by the "vimrun" command.  The 
"vimrun.exe" must be in the path for this to work.

My knowledge in Windows APIs and gVim source code is very limited; so this is probably a dumb question: instead of trying to intercept the calls, is it possible & easier to change the shell-x64/86.dll into an vimrun.exe that is set to the beginning of the &rtp?

Or create a fake vimrun.exe that do something similar to what is performed in shell-x64/86.dll and then redirect to the default vimrun.exe?

[xolox]

I was indeed thinking of "overriding" vimrun.exe (or a similar approach) but unfortunately I think that's not possible. When executing an external console program non-interactively (hidden), we'll most likely be interested in the output of the program. However programs without a console window cannot report output and instead crash (I've read in a couple of places).

So the only remaining option is to tell Windows that we want to hide (but not remove) the console window before we start the external program. To do that I will have to intercept and override all calls from Vim to Windows API functions like CreateProcess() and change the parameters so that the console window of the external program is hidden.

MS Detours and MHook provide a way to intercept Windows API calls, but MS Detours is not an option (licensing) and so far I haven't gotten MHook to compile.

[mMontu]

Does changing 'shell' falls on the same problem? From :h lmake:

The ":make" command executes the command given with the 'makeprg' option.
This is done by passing the command to the shell given with the 'shell'
option.  This works almost like typing

    ":!{makeprg} [arguments] {shellpipe} {errorfile}".

[mMontu]

(I know that you already use it in this plugin, but I doesn't understand how)

[mMontu]

It seems that there is another option to hiding the console window: using a Gui application..
I don't know much about the implications of using a gui app instead of a console, though.