support configurable list types

[bhcleek]

• Prefer the quickfix window for commands whose output is considered to
  be errors for more than current buffer. e.g. :GoBuild.
• Prefer the location list window for commands whose output is related
  specifically to the current buffer only (e.g: :GoFmt and
  :GoImplements).
• Rename 'g:go_loclist_height' to 'g:go_list_height'.
• Add a new option, 'g:go_list_type', to configure whether to always use
  the quickfix window, a location list window, or to vary based on the
  preferred window as documented above.

@fatih I'm not sure if you'd want to keep the default as I've coded it. The default here is to vary the list by the command, but that changes the 1.4 behavior, and we'd talked about preserving the 1.4 behavior by default.

I tried to update the relevant documentation where the location list was referenced to be accurate according to the preferred windows that I described above, but please double check my work.

Consider this a start point - I realize you may have lots of feedback; I'm happy to do any rework that you find necessary.

Fixes #696

[fatih]

Thanks @bhcleek for the PR. I'm aware of this just hadn't the time to look at in more detail. This is a needed PR as it's really annoying to me too lately. So I want to use this to test how it works with quickfix + neovim. I'll let you know and also add comments.

[bhcleek]

Thank you for the update @fatih. I'm really looking forward to getting this merged; I've been using it since I submitted it and am pleased with the lists.

[fatih]

@bhcleek could you rebase it again on top of master? Sorry for the inconvenience but seems like it's not mergable anymore due recent changes.

[bhcleek]

@fatih I've rebased on top of master.

[fatih]

Can you rename all a:quickfix variables to a:ltype (or a:listype) ? It's confusing as it's not clear what it is.

[fatih]

I'm not sure if we need this. It's yet another abstraction and seems like we don't need it. Can you remove it? Anywhere else just let use strings. Like:

if a:listype == "quickfix"
endif

This is more readable and we don't need to manually parse what 0 or 1 means.

[fatih]

@bhcleek so as a final note, remove the Type() function and pass strings, such as "quickfix" or "locationlist" to each appropriate function.

[bhcleek]

There are two different times that resolution of the preferred window and g:go_list_type needs to happen; in the go#list functions themselves to decide which type of window to manipulate, and also in the callers of those functions, to decide which kind of command to run (e.g. lmake vs make). To satisfy that need, removing go#list#Type(), will require that the code that it contains be sprinkled in lots of places, because of the need to resolve the preferred window according to how the user has set g:go_list_type. With that in mind, do you still want go#list#Type() removed?

[bhcleek]

@fatih I refactored to pass strings instead of integers. I'll wait to make the change to remove go#list#Type() until I get confirmation that you want it removed in light of my previous comment. Perhaps it would be better to rename it so its utility is clearer?

[fatih]

@bhcleek sorry but I still didn't grasp the importance of go#list#Type(). It returns the passed string back to you. You have that information already? For example right now this is how the code is written:

    let l:listtype = go#list#Type(a:listtype)
    if l:listtype == "locationlist"
        return getloclist(0)
    else
        return getqflist()
    endif

But you can also write this as:

    if a:listtype == "locationlist"
        return getloclist(0)
    else
        return getqflist()
    endif

So what's the difference ?

[bhcleek]

go#list#Type() doesn't just return what was passed to it. It returns the list type based on g:go_list_type. It returns what was passed in (e.g. a:listtype) only if g:go_list_type is not set to always use the quickfix or location list window.

Maybe this will help: https://github.com/bhcleek/vim-go/blob/master/doc/vim-go.txt#L1010

[fatih]

Thanks @bhcleek, now it makes sense 👍 There is nothing that keeps me to merge this, I've already pulled and working with. Let me use this way 1,2 day and I'll merge it (so I can catch any errors meanwhile as I'm heavily using vim-go while developing our projects in my full time job). Thanks again 👍

[fatih]

Thanks @bhcleek a lot for your contribution. This is very useful and most needed feature we needed. If you see any errors or any improvements please feel free to open an issue or send a PR to discuss further.

[bhcleek]

I'm happy to help @fatih. If I find any problems, I'll submit a PR to get them fixed. FWIW, I've been using this for two weeks successfully.

👍

[svanharmelen]

Really like this one 👍 Thx!