Re: sourcing a sh file in zsh

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

On 2009-01-17 at 12:15 -0800, Bart Schaefer wrote:
> This gets very tricky, however, when applied to functions that are
> actually designed for zsh.  An implicit preset of options implies an
> implicit restore later, but a zsh function which deliberately does
> NOT "setopt localoptions" is expecting any setopt it executes to
> persist after the function exits.  It'll be complicated to keep track
> of which options should be restored because of implicit preset, and
> which ones should not be restored because of explicit change.

True.  My usage scenario was too narrow -- the functions being defined
would never use setopt since they'd be non-zsh functions, except at the
top-level where this new feature would be enabled.

In a sense, I'm creating something akin to a namespace, but being more
of a setopt-value-space.  I'm wondering if it's worth looking at this
from a different angle and whether or not there's something along the
lines of a namespace concept which it's worth implementing, with setopts
being local to a namespace and being able to source a script in another
namespace, created at source time.

Now, a separate pair of items of things I should explore when I have
time, as approaches, tie into this but I hadn't noticed the connection
before (down-side of what is mostly an unordered collection of crazy
ideas worked in with small nits):

----------------------------8< cut here >8------------------------------
Namespaced variables?
  Default is 'main'
  znamespace valid-var-name   to change current, reverts on return from scope?
  Case-insensitive, so that you can use consistent capitalisation for the entire qualified var-name
  ${namespace.varname} to get others (braces mandatory)
  All zsh builtin params also available in 'zsh' namespace.
  So ${ZSH.SECONDS}, ${zsh.fpath}, etc.
  All existing vars bound as before.
  Can we handle multiple names bound to exact same var, besides the tied FOO/foo case?
    -- only the namespace case-insensitive
  ZSHZLE.* for widget variables which persist, such as killring?
  How to handle assignment?  Make dot valid at parse-time separately?

Alternatively:
  Methods via var.method, so that scalarvar.charlen and sv.bytelen give results.
  Have special namespace variables which have the method return any variable
    within that namespace so that you can chain.
  Thus ${zsh.fpath.count} gives the number of elements in the zsh fpath array.
----------------------------8< cut here >8------------------------------
  (DISCLAIMER: my notes contain crazy ideas)

So, is it instead a case of making setopts namespace-bound, thinking
more carefully about syntax than my rough scratchings above, moving much
of completion into a separate namespace and then have functions called
from outside the namespace switch namespace upon invocation and restore
on departure, mechanics much as I described for setopt, but abstracted
out to a container for whatever semantics we want to make
switchable?

Please, bang this idea about a bit, shoot down or refine as appropriate.

-Phil