Bug with emulation in completion?

Bug with emulation in completion?

[Felipe Contreras]

Hi,

Check this script:

_foo_1 () {
  emulate -L zsh
  _arguments '--one' '--two'
}

_foo_2 () {
  _arguments '--one' '--two'
}

compdef _foo_1 foo

With _foo_2 the completion cycles the options properly, but not with _foo_1.

Ideas?

-- 
Felipe Contreras

Re: Bug with emulation in completion?

[Bart Schaefer]

On Nov 22, 10:41am, Felipe Contreras wrote:
}
} _foo_1 () {
}   emulate -L zsh
}   _arguments '--one' '--two'
} }
} 
} compdef _foo_1 foo

The completion system sets up a very specific setopt state that all the
supplied completion functions such as _arguments expect to have in scope
at the time they are run.

There have recently been some changes that would allow that state to be
made "sticky" for individual functions, so that it is automatically put
in place when they are called, but that is only available in development
builds of the shell at this point (and hasn't actually been applied to
the completion functions even there AFAIK).

The workaround is to introduce an additional function scope for the new
emulation state that you need, call that, and then call _arguments after
it returns (where the previous state will have been restored).  In recent
zsh releases you can do that with an anonymous scope like so:

_foo_1 () {
  () {
    emulate -L zsh
    : do something you need to do
  }
  _arguments '--one' '--two'
}

In older zsh you'll have to explicitly declare a second function to be
called from within _foo_1.

Re: Bug with emulation in completion?

[Peter Stephenson]

On Thu, 22 Nov 2012 09:47:47 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> There have recently been some changes that would allow that state to be
> made "sticky" for individual functions, so that it is automatically put
> in place when they are called, but that is only available in development
> builds of the shell at this point (and hasn't actually been applied to
> the completion functions even there AFAIK).

We didn't even really decide how it should be done.

It might be more useful to apply the stickiness to any function which
wasn't part of the normal completion system and needed e.g. ksh
emulation.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Bug with emulation in completion?

[Bart Schaefer]

On Nov 24,  8:33pm, Peter Stephenson wrote:
}
} It might be more useful to apply the stickiness to any function which
} wasn't part of the normal completion system and needed e.g. ksh
} emulation.

Unfortunately what he wants to do is call zsh-mode functions from the
ksh-mode functions.  Unless we screw with the dynamic inheritence model
[change stickyness rule #2 from the doc] so that the emulation mode is
cleared when calling out to a function that does not have the equivalent
stickyness -- something I'm loathe to advocate, for a number of reasons
-- it's not really an option to make the ksh functions sticky.

I suppose we could add another option or the like to "emulate" that has
the effect of resetting the option state as if the current function had
returned.  E.g.,

  some_function () {
    : do something
  }
  zsh_function () {
    emulate -L zsh
    ksh_function
  }
  ksh_function () {
    emulate -L ksh
    : do some stuff
    emulate -c caller some_function # called as if from zsh_function
  }

Replace "-c caller" with -C or some other flag as you will, the above is
just for example.  But this gets into assorted questions such as whether
"-c caller" has any effect when localoptions is not [yet] set, etc.

Re: Bug with emulation in completion?

[Felipe Contreras]

> On Nov 22, 10:41am, Felipe Contreras wrote:
> }
> } _foo_1 () {
> }   emulate -L zsh
> }   _arguments '--one' '--two'
> } }
> }
> } compdef _foo_1 foo
>
> The completion system sets up a very specific setopt state that all the
> supplied completion functions such as _arguments expect to have in scope
> at the time they are run.
>
> There have recently been some changes that would allow that state to be
> made "sticky" for individual functions, so that it is automatically put
> in place when they are called, but that is only available in development
> builds of the shell at this point (and hasn't actually been applied to
> the completion functions even there AFAIK).
>
> The workaround is to introduce an additional function scope for the new
> emulation state that you need, call that, and then call _arguments after
> it returns (where the previous state will have been restored).  In recent
> zsh releases you can do that with an anonymous scope like so:
>
> _foo_1 () {
>   () {
>     emulate -L zsh
>     : do something you need to do
>   }
>   _arguments '--one' '--two'
> }
>
> In older zsh you'll have to explicitly declare a second function to be
> called from within _foo_1.

That's not what I need.

_foo_2 () {
  emulate -L zsh
 _arguments '--one' '--two'
}

_foo_3 () {
  : different stuff
}

_foo_1 () {
  emulate -L ksh
  : do something
  _foo_$1
}

So now instead of simply doing 'emulate -L zsh' on the few functions
that I'm interested in, I have to shuffle around to code so that ksh
and zsh code doesn't mix together =/

Cheers.

-- 
Felipe Contreras

Re: Bug with emulation in completion?

[Bart Schaefer]

On Nov 24,  2:47pm, Felipe Contreras wrote:
} Subject: Re: Bug with emulation in completion?
}
} > The workaround is to introduce an additional function scope for the new
} > emulation state that you need, call that, and then call _arguments after
} > it returns (where the previous state will have been restored).  In recent
} > zsh releases you can do that with an anonymous scope [...]
} 
} That's not what I need.
} 
} _foo_2 () {
}   emulate -L zsh
}  _arguments '--one' '--two'
} }
} 
} _foo_3 () {
}   : different stuff
} }
} 
} _foo_1 () {
}   emulate -L ksh
}   : do something
}   _foo_$1
} }
} 
} So now instead of simply doing 'emulate -L zsh' on the few functions
} that I'm interested in, I have to shuffle around to code so that ksh
} and zsh code doesn't mix together =/

Well, yes.  The completion function suite was not designed to be
programmed in ksh-speke.

Presumably someone is going to call "_foo_1 2" or "_foo_1 3".

So what you want is

_foo_2 () {
  _arguments '--one' '--two'
}

_foo_3 () {
  : different stuff
}

_foo_1 () {
  local needed later
  () {
    emulate -L ksh
    : do something possibly with needed=this and later=that
  }
  _foo_$1 $needed $later
}

If that's not sufficient to isolate the ksh-ness, it ought to work to
replace "emulate -L zsh" with

    setopt localoptions localtraps "${_comp_options[@]}"

which is what _main_complete uses to set up the options when completion
begins, but I won't promise that emulate-ing into ksh and then setopt-ing
your way out of it won't leave something odd behind.