Re: [PATCH] vcs_info: Use ‘command’ prefix to call version control programs

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Frank Terbeck wrote on Wed, Oct 22, 2014 at 11:28:24 +0200:
> Bart Schaefer wrote:
> > On Oct 22,  6:24am, Manfred Lotz wrote:
> [...]
> > } VCS_INFO_get_data_svn:31: bad set of key/value pairs for associative
> > } array
> [...]
> > I suppose VCS_INFO_get_data_svn ought to use "command ${vcs_comm[cmd]}"
> > instead to bypass any such wrapper functions.  There are around three
> > dozen places in Functions/VCS_Info/Backends/* that could similarly use
> > the "command" prefix if we want to support Manfred's style of use.
> 
> This patch implements Bart's suggestion.
> ---
> 
>     I think this is reasonable. I hope, people don't count on
>     wrapper functions to work to achieve some sort of sinister
>     hack. :)
> 

I hate to say this after you already wrote the patch, but:

There are legitimate use-cases for wrapper functions, and your patch
would break them.  (For example, someone might use a wrapper function
to dispatch to a different svn binary depending on the working copy they
are in.)

Alternative solutions include:

- Asking people who write svn() functions that vcs_info cannot use to
  set the 'command' style to /usr/local/bin/svn, e.g.,

    zstyle ':vcs_info:svn:*' command =svn

  (I assume most svn() wrapper functions out there are compatible with
  vcs_info.)

- Patching the wrapper function to behave differently when invoked by
  vcs_info.  The different behaviour could be, for example, adding
  --non-interactive or dispatching to /usr/local/bin/svn without any
  wrapping logic.  I'm not sure what the best way to detect "being
  invoked by vcs_info" would be --- perhaps "[[ ! -t 1 ]]"?

I would also be interested in knowing what the specific problem was in
the interaction between the OP's wrapper and vcs_info.  (And in the
value of `svn --version -q`.)

Cheers,

Daniel