> It's okay to support buffer-local values, but using the value of the
> variable will do that automatically; you don't have to verify it has a
> local binding.  What I don't understand is why does your code _reject_
> global bindings.  If some user wants to set up a global value for some
> reason, or have a default global value and special local values in
> some cases, why should we prevent that?

You are absolutely right, now I realize that local-variable-p is overly
conservative. Since I didn't define the variable in the first place I had to do
the check and even then boundp would have been better.

> > But now I'm thinking maybe it makes sense to add it as defvar-local under the
> > go-ts-mode? Please guide me with what will be the correct way to implement it.
>
> Yes, defvar-local could be what we want.  But I first would like to
> understand what is special about this variable that it should be
> buffer-local.

With the improved understanding, I believe defcustom would be better for the
variable. Then I don't even need the the boundp check since the variable is
always present and it can be replaced by just the non-nil check instead.

As an improvement, I'm also changing the variable-type to a list of strings
instead of a single comma separated string.

I'm submitting an updated Patch with the following changes:
* Add commit log
* Fix the text formatting.
* Update the keybindings to use the C-c C-t prefix.
* Improve regexp matching to be more strict.
* Define =go-ts-mode-build-tags= variable in the module and use it in the test
  functions.

-- 
Ankit