On Mar 7, 11:34am, Stephane Chazelas wrote:
}
} Sorry, I realise I wrote the opposite of what I meant.
}
} What I meant was that instead of introducing a cumbersome
} confusing syntax, We could get rid of "emulate" (yes the
} contrary of what I actually wrote) and do it with setopt.
That doesn't cover the "emulate zsh -c ..." semantics. To replace
the current (even without workers/30320) emulate behavior, we'd need:
(1) two special parameters for each emulation mode, one with the set
of options from "emulate -R" and the other the minimal set;
(2) an extension of the "eval" command to unwind the option state and
implement "sticky emulation" (this can't be based on localoptions as
the emulated code needs license to freely change that);
(3) a different mechanism to control the (small) set of behaviors that
depend on the global emulation mode rather than on the setopt values;
(4) a replacement for the other use of "emulate" which is to test what
the current emulation mode *is*, e.g., to be able to discover that the
shell was started with ARGV0=sh or similar.
I'm not sure the sum of that ends up being any less cumbersome, not
to mention breaking ten years' worth of zsh functions that start with
"emulate -LR zsh".
I also disagree that the emulate syntax is cumbersome or confusing,
as it's very similar to sticking the word "emulate" in front of the
command you'd use to start a new external shell. When using -c it's
cumbersome to properly quote a whole function definition, but to fix
that "emulate" (or "eval" in (2) above) would have to be a keyword.
"emulate zsh -c ..." is actually pretty close in semantics to
"function { setopt localoptions $zsh_options; ... }" except for the
parenthetical caveat in (2) above, so if not for (3) above we could
use an extension to the function keyword instead of eval, which would
eliminate the quoting problem without creating any new keywords.
This may be worth thinking about, independently of emulate-vs-setopt.
--
Barton E. Schaefer