Unintended side-effects of "emulate -c" ?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

} emulate command might just as well parse other startup-time options
} besides just -c. [...]
} I've got this 98% working by factoring a loop out of init.c:parseargs()

I'm now reasonably sure I have this 100% working.

In the course of doing so I noticed some side-effects of "emulate -c" that
have nothing to do with my fiddling with it.

First, some context:

torch% (){ setopt localoptions restricted } && print $options[restricted]
on
torch% setopt +r
setopt: can't change option: -r

I.e., "restricted" is normally a sticky option.  Once you turn it on, even
in a function context with localoptions in effect, it cannot be turned off.

Now consider (starting again from zsh -f):

torch% emulate sh -c 'setopt restricted' && print $options[restricted]
off

That is, it's possible to have a restricted emulation, and then revert
back to unrestricted when the emulation completes.  This is actually a
nice feature, one that was never do-able before because there was no
scope in which "localoptions" was guaranteed to remain in effect all
the way to the end of the scope.  But ... was it intentional?

Note that for obvious reasons the opposite is prevented, that is, you
can't temporarily become unrestricted:

torch% set -r
torch% emulate sh -c 'unsetopt restricted' && print $options[restricted]
unsetopt: can't change option: restricted
on

I've retained this behavior in my tweaked emulate:

torch% emulate zsh -rc 'print $options[restricted]'
on
torch% print $options[restricted]
off
torch% set -r
torch% emulate zsh +rc 'print $options[restricted]'
emulate: can't change option: -r
on

Restricted-ness is not "sticky" the way emulation mode is, so you can't
use this trick to create a function that is always restricted ... but I
suspect it might not be too difficult to change that.

Another less desirable unintended side-effect:

torch% emulate zsh -c 'set -o vi'

This is equivalent to "bindkey -v" and leaks out of the emulate scope.
A similar thing happens with sunkeyboardhack and banghist.

On a related note, naming the sunkeyboardhack option to setopt even with
no change in state, discards any user-assigned value of $KEYBOARD_HACK;
and assigning to KEYBOARD_HACK turns on the behavior without changing
the setting of the option.  That should at least be documented?