bug#70939: [PATCH] Add commands to run unit tests in go-ts-mode

[Eli Zaretskii <eliz@gnu.org>]

> From: Ankit Gadiya <ankit@argp.in>
> Date: Thu, 16 May 2024 20:33:31 +0530
> Cc: Randy Taylor <dev@rjt.dev>, 70939@debbugs.gnu.org
> 
> > If the variable is specific to go-ts-mode, it should indeed be
> > prefixed with "go-ts-".  But I don't see this variable in
> > go-ts-mode.el nor in the patch (did I miss something?), and I don't
> > understand why the above condition insists on using only a
> > buffer-local value of the variable in the first place?  What's wrong
> > with having a global value for the variable?
> 
> I'm not yet familiar with Elisp-idioms but I'll explain my idea and why I used
> the variable this way.
> 
> The build tags can be unique to the specific project and sometimes even per
> go package. So I thought to make it buffer specific rather than a global
> variable defined in the init.el. I'm using these changes on my machine and I'm
> defining the build tags in the dir-locals file. This way the variable is always
> available for the mode commands to access.

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?

> 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.