Re: [go-nuts] goimports flag parity with gofmt

2017-06-13 Thread 'Sergiy Byelozyorov' via golang-nuts
Yes, but what I need is to run "goimports" and then "gofmt -s". If
goimports supported -s, then I would be able to do what I need, but not
with current vim-go implementation.

On Tue, Jun 13, 2017 at 3:00 PM Fatih Arslan  wrote:

> I think there is a misunderstanding here. People somehow don't read the
> manuals or the changelog when I release a new version. We have the
> following setting for  (which was released recently with v1.13):
>
>   let g:go_fmt_options = {
> \ 'gofmt': '-s',
> \ 'goimports': '-local mycompany.com',
> \ }
>
> Everyone who can see this immediately can see how this already solves this
> problem. As you see, vim-go can use different kind of options for each
> different binary name.
>
>
> On Mon, Jun 12, 2017 at 7:55 PM Brad Fitzpatrick 
> wrote:
>
>> Use the tool that does what you want.
>>
>> We don't have to put all functionality into all binaries.
>>
>> If vim-go makes assumptions that one helper binary does all
>> functionality, yes, please fix vim-go.
>>
>> On Mon, Jun 12, 2017 at 9:12 AM, sergiyb via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> This is still bothering us in 2017. I'd love to be able to run goimports
>>> on save in Vim, but also would like to simplify code (-s option). I use
>>> vim-go plugin, so I guess I can submit a pull request asking the plugin to
>>> run both commands on save, but I do not understand why the workaround
>>> instead of command parity? Is it something no one has had time to look into
>>> yet or is it too hard to implement with current goimports implementation?
>>>
>>> On Friday, February 21, 2014 at 6:36:59 AM UTC+1, bradfitz wrote:

 Oh, you did update goimports.

 gofmt and goimports both had their tab options removed.

 But yes, goimports doesn't have cpuprofile, -r, or -s.  Not sure how
 much it matters.  No editors really use those, do they?  If you want to do
 it by hand, gofmt is still there.



 On Thu, Feb 20, 2014 at 9:35 PM, Brad Fitzpatrick 
 wrote:

> I don't think you're running the correct binary then, because:
>
> $ rm $(which goimports)
> $ go get -v -u code.google.com/p/go.tools/cmd/goimports
> $ goimports -h
> usage: goimports [flags] [path ...]
>   -d=false: display diffs instead of rewriting files
>   -e=false: report all errors (not just the first 10 on different
> lines)
>   -l=false: list files whose formatting differs from goimport's
>   -w=false: write result to (source) file instead of stdout
>
>
>
> On Thu, Feb 20, 2014 at 9:32 PM, Vasiliy Tolstov 
> wrote:
>
>> 2014-02-21 9:29 GMT+04:00 Brad Fitzpatrick :
>> > You're running old binaries of each.
>>
>>
>> Hmm. I'm try new goimports but nothing different:
>>
>> go get -v -x -u code.google.com/p/go.tools/cmd/goimports
>> code.google.com/p/go.tools (download)
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>> hg pull
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>> hg tags
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>> hg branches
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>> hg update default
>> WORK=/tmp/go-build706264051
>> code.google.com/p/go.tools/imports
>> mkdir -p $WORK/code.google.com/p/go.tools/imports/_obj/
>> mkdir -p $WORK/code.google.com/p/go.tools/
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports
>> /usr/lib64/go/pkg/tool/linux_amd64/6g
>> 
>> -o
>> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6 -p
>> code.google.com/p/go.tools/imports -complete -D
>> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports -I
>> $WORK -I /home/vtolstov/devel/go/pkg/linux_amd64 ./fix.go ./imports.go
>> ./sortimports.go ./zstdlib.go
>> /usr/lib64/go/pkg/tool/linux_amd64/pack grcP $WORK
>> $WORK/code.google.com/p/go.tools/imports.a
>> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6
>> mkdir -p /home/vtolstov/devel/go/pkg/linux_amd64/
>> code.google.com/p/go.tools/
>> cp $WORK/code.google.com/p/go.tools/imports.a
>> /home/vtolstov/devel/go/pkg/linux_amd64/
>> code.google.com/p/go.tools/imports.a
>> code.google.com/p/go.tools/cmd/goimports
>> mkdir -p $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/
>> mkdir -p $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/exe/
>> cd /home/vtolstov/devel/go/src/
>> code.google.com/p/go.tools/cmd/goimports
>> /usr/lib64/go/pkg/tool/linux_amd64/6g
>> 
>> -o
>> $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/_go_.6 -p
>> code.google.com/p/go.tools/cmd/goimports -complete -D
>> _/home/vtolstov/devel/go/src/code.google.com/p/go.to

Re: [go-nuts] goimports flag parity with gofmt

2017-06-13 Thread &#x27;Sergiy Byelozyorov&#x27; via golang-nuts
Ah. Good point. Added

autocmd BufWritePre *.go :GoFmt
autocmd BufWritePre *.go :GoImports

to my .vimrc. Thanks.

On Tue, Jun 13, 2017 at 3:38 PM Fatih Arslan  wrote:

> No you can do it. We have two commands, called :GoImports and :GoFmt. You
> can set the new setting and then call first :GoImports and then :GoFmt.
> With a little vim script you could create a single command that executes
> them in order.
>
> On Tue, Jun 13, 2017 at 4:07 PM Sergiy Byelozyorov 
> wrote:
>
>> Yes, but what I need is to run "goimports" and then "gofmt -s". If
>> goimports supported -s, then I would be able to do what I need, but not
>> with current vim-go implementation.
>>
>> On Tue, Jun 13, 2017 at 3:00 PM Fatih Arslan  wrote:
>>
>>> I think there is a misunderstanding here. People somehow don't read the
>>> manuals or the changelog when I release a new version. We have the
>>> following setting for  (which was released recently with v1.13):
>>>
>>>   let g:go_fmt_options = {
>>> \ 'gofmt': '-s',
>>> \ 'goimports': '-local mycompany.com',
>>> \ }
>>>
>>> Everyone who can see this immediately can see how this already solves
>>> this problem. As you see, vim-go can use different kind of options for each
>>> different binary name.
>>>
>>>
>>> On Mon, Jun 12, 2017 at 7:55 PM Brad Fitzpatrick 
>>> wrote:
>>>
 Use the tool that does what you want.

 We don't have to put all functionality into all binaries.

 If vim-go makes assumptions that one helper binary does all
 functionality, yes, please fix vim-go.

 On Mon, Jun 12, 2017 at 9:12 AM, sergiyb via golang-nuts <
 golang-nuts@googlegroups.com> wrote:

> This is still bothering us in 2017. I'd love to be able to run
> goimports on save in Vim, but also would like to simplify code (-s 
> option).
> I use vim-go plugin, so I guess I can submit a pull request asking the
> plugin to run both commands on save, but I do not understand why the
> workaround instead of command parity? Is it something no one has had time
> to look into yet or is it too hard to implement with current goimports
> implementation?
>
> On Friday, February 21, 2014 at 6:36:59 AM UTC+1, bradfitz wrote:
>>
>> Oh, you did update goimports.
>>
>> gofmt and goimports both had their tab options removed.
>>
>> But yes, goimports doesn't have cpuprofile, -r, or -s.  Not sure how
>> much it matters.  No editors really use those, do they?  If you want to 
>> do
>> it by hand, gofmt is still there.
>>
>>
>>
>> On Thu, Feb 20, 2014 at 9:35 PM, Brad Fitzpatrick > > wrote:
>>
>>> I don't think you're running the correct binary then, because:
>>>
>>> $ rm $(which goimports)
>>> $ go get -v -u code.google.com/p/go.tools/cmd/goimports
>>> $ goimports -h
>>> usage: goimports [flags] [path ...]
>>>   -d=false: display diffs instead of rewriting files
>>>   -e=false: report all errors (not just the first 10 on different
>>> lines)
>>>   -l=false: list files whose formatting differs from goimport's
>>>   -w=false: write result to (source) file instead of stdout
>>>
>>>
>>>
>>> On Thu, Feb 20, 2014 at 9:32 PM, Vasiliy Tolstov 
>>> wrote:
>>>
 2014-02-21 9:29 GMT+04:00 Brad Fitzpatrick :
 > You're running old binaries of each.


 Hmm. I'm try new goimports but nothing different:

 go get -v -x -u code.google.com/p/go.tools/cmd/goimports
 code.google.com/p/go.tools (download)
 cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
 hg pull
 cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
 hg tags
 cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
 hg branches
 cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
 hg update default
 WORK=/tmp/go-build706264051
 code.google.com/p/go.tools/imports
 mkdir -p $WORK/code.google.com/p/go.tools/imports/_obj/
 mkdir -p $WORK/code.google.com/p/go.tools/
 cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports
 /usr/lib64/go/pkg/tool/linux_amd64/6g
 
 -o
 $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6 -p
 code.google.com/p/go.tools/imports -complete -D
 _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports -I
 $WORK -I /home/vtolstov/devel/go/pkg/linux_amd64 ./fix.go
 ./imports.go
 ./sortimports.go ./zstdlib.go
 /usr/lib64/go/pkg/tool/linux_amd64/pack grcP $WORK
 $WORK/code.google.com/p/go.tools/imports.a
 $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6
 mkdir -p /home/vtolstov/devel/go/pkg/linux_amd64/
 code.google.com/p/go.tools/
 cp $WORK/code.google.com/p/