GoRun currently only cares about gofiles whereas the actual go run command allows for command line arguments as well. It would be nice if GoRun could be made to pass along anything after the command which would make it much more useful while writing cli utilities
Makes sense. Let me look at it Karl :+1:
Hi @liminal. I've looked at this today for possible implementations. The problem is it would break the current :GoRun functionality. Current this is how we define :GoRun:
Build and run your current main package. By default all main files for the
current file is used. If an argument is passed, 'expand' is used as file
selector. For example use `:GoRun %` to select the current file only.
As you see, we use it to select files. So implementing this would break the current function and I'm not sure if I want to this. What we could is to add a new command but I would like to keep the namespace clean. I'm not sure how do implement it, tinkering with it :)
I don't see the problem. go run takes file arguments as well so I don't see why adding arguments would break that functionality.
go help run
usage: go run [build flags] [-exec xprog] gofiles... [arguments...]
This is not possible because it's not backwards compatible. As I said you are looking for go runs argument. By default :GoRun excepts to receive only files, no other argument can be passed. Once you try to pass any other argument it'll break the previous functionality.
Example:
:GoRun -enabled %
Is % an argument to -enabled flag or it's the current source file in terms of viml ? For example:
:GoRun %
This works, because % expands to the current file. I hope you get what I mean. If we want to let pass arguments we need to either introduce a new command or you should execute it directly with the ! directive:
:!go run -enabled -name -test
To be honest I still don't see how it's a problem. Any case that breaks wouldn't have worked before anyway, but since I can't vim-script even a little I'll defer to your judgement and just use the !go direct command
I gave the example above with % and you still don't see the problem here? Here is a snippet:
http://play.golang.org/p/hDRUVMyZu8
Run with go run demo.go -name %, and see the output: %
This is not compatible what we have, we are passing the first argument of :GoRun to the expand() function, unless we give this feature there is no way I can pass any other arguments. The % and many other viml placeholders , listed here:
% current file name
# alternate file name
#n alternate file name n
<cfile> file name under the cursor
<afile> autocmd file name
<abuf> autocmd buffer number (as a String!)
<amatch> autocmd matched name
<sfile> sourced script file or function name
<slnum> sourced script file line number
<cword> word under the cursor
<cWORD> WORD under the cursor
<client> the {clientid} of the last received
can't be used once we abandon the current approach. :GoRun is using these place holders. Can you please provide something you say it's not a problem and would work with this too? For example how do you think to solve go run demo.go -name %, which is both correct in terms of a normal usage and in terms of vim's placeholder expressions.
Btw, I'm not against your suggestion, I'm just trying to tell that :GoRun in its current form is not something we can break. If we want to implement it we need to provide a new command that completely abandons expanding placeholders and just pass any argument (up to 20, which is a viml limit) to go run. This is possible with a new command.
I understand the wish not to break stuff but I'm asking what functionality _that works today_ with :GoRun would not work if you ran expand on the arguments to GoRun and then passed it to go run
The only functionality that works today is :GoRun (no arguments) and :GoRun {expand} which currently only works with passing something that expands to a file name. My point was that the command you use as an example doesn't work today anyway so no matter how you'd chose to support it it wouldn't break backwards compatibility.
personally I'd happily just have everything expand()ed and passed to GoRun and live with having problems the 0% of the time that I want to actually pass the unexpanded percentage sign as an argument but YMMV
Now since I don't know how to use expand() properly it might be that there's no reasonable way of supporting additional arguments and fair enough, let's not then. I'm just saying I don't see how supporting additional command forms that aren't supported today would break the current form of GoRun
And if it really is this big of a problem then let's just not add it. I thought it would be a reasonable functionality but it's no biggie for me to just use :!go
@fatih , any thoughts on this now ?
@fatih, or now ?
I see the point from fatih, but anyway I would love to see him to add that feature. Only in the most simple scenarios you will not have to use app arguments.
In my conf I use
autocmd FileType go nmap <leader>r <Plug>(go-run)
If I need parameters I remap in runtime in that way:
:nmap <leader>r :!go run main.go coins.go tester.go coins<CR>
I really like your suggestion @rudolfschmidt. Since changing GoRun would likely break functionality I just have this in my config:
autocmd FileType go nmap<leader>r :!go run %
Notice how I don't have the carriage return at the end, so I can easily add the arguments I need.
If the file that needs to be run changes or isn't the current file you could create a variable and just set the value of the variable whenever you enter your workspace.