use emulate -L in setup.zsh to keep options intact

[de-vri-es]

Should resolve issue #686. The original overwrites options explicitly set by the user in their zshrc.

[de-vri-es]

I forgot to actually call _catkin_source_setup but that's fixed now.

[dirk-thomas]

@wjwwood Can you please verify that this works well on Mac OS. E.g. with a small workspace like ros_core and making sure that the environment hooks are sourced correctly.

[de-vri-es]

@dirk-thomas Do you know something that would fail without emulation? Because like I said it worked fine for me without emulation as well, I'm not sure what to test. I don't notice any difference with this PR (besides my option not being overwritten any more), but I also didn't notice any difference with/without emulation.

[wjwwood]

It originally comes from this: #182

But we have seen zsh not behave like sh (dash) in many cases, especially when dealing with IFS.

[de-vri-es]

I don't see the behaviour described in #182, with or without emulation (any method of enabling/disabling it). My guess is it got fixed in a different manner.

By the way, it seems that emulate sh does not propagate to functions defined while the emulation mode was active. Using emulate -L or the original method does not matter. I believe the proper way to do something like that in zsh is this:

emulate sh -c '_catkin_source_setup() {
  source "$_CATKIN_SETUP_DIR/setup.sh"
}
_caktin_source_setup

This enables sticky emulation which is inherited by all functions defined by that function. However, doing that I do notice a difference, namely that autocompletion doesn't work any more at all (at least for rosservice).

For now I still believe this PR is an improvement since it seems to preserve behaviour (as far as I can tell, but please double-check) but it doesn't overwrite options set by the user any more.

[dirk-thomas]

Closing in favor of #692. Please see #686 for more information.