Re: PATCH: sticky emulation

[Bart Schaefer <schaefer@brasslantern.com>]

On Feb 10, 11:03pm, Peter Stephenson wrote:
} Subject: PATCH: sticky emulation
}
} This is how I envision (and have already described, at least briefly)
} sticky emulation for functions working.

This all seems quite reasonable to me, particularly because the
implementation appears to be a straightforward change to the code --
tends to imply that it fits naturally into the existing semantics.

Nit-pick:  The patch to Src/hashtable.c is a no-op.

} Note that sticky emulation is not propagated to autoloaded functions,
} neither when the autoload is set up nor when they are loaded

What about zcompiled functions?  Obviously there's no special case for
them, but their treatment may be worth explanation at doc time.

} - Sticky emulation does not cause options to be saved and reset while
} executing another function with the same sticky emulation.

I think this is fine.

} - Functions without sticky emulation are not specially handled, so are
} entered with no option changes, and do not have options reset on
} exit except as normal shell handling, e.g. LOCAL_OPTIONS.

I wouldn't expect this to behave any differently.

} Someone can probably tell me if I should be keeping the RESTRICTED
} and PRIVILEGED options when restoring options after executing a sticky
} function, as for LOCAL_OPTIONS handling but not as for "emulate"; my
} brain hurts.  I think the answer is "no" because it looks more like the
} latter case than the former, but it may not be that simple.

I think "no" is also the right answer; I've always been a little puzzled
about why those were made exceptions to LOCAL_OPTIONS.  I think the
answer to the latter is related to the fact that there's otherwise no
way to force *any* option to persist across LOCAL_OPTIONS.