Re: Bug with emulation in completion?

[Bart Schaefer <schaefer@brasslantern.com>]

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.