Re: emulate with options other than -c is broken

[Bart Schaefer <schaefer@brasslantern.com>]

On Oct 11,  8:53pm, Peter Stephenson wrote:
} Subject: Re: emulate with options other than -c is broken
}
} The next question is, do we want to use this for functions autoloaded
} by the completion system?  The argument against is that it changes
} the behaviour 

Hmm.  The difficulty I see with this is that compinit is used to load
widget functions (#compdef -k / -K) and other helpers (#autoload) for
which the set of $_comp_options do not necessarily apply.  Futhermore,
I know I use #autoload in files that don't necessarily have anything
to do with completion, just because I know compinit will pick them up
for me.  Pulling those setopts out of $_comp_setup into an emulate
wrapper around the autoload call in compinit (if that is indeed what
you contemplate here) would apply them too broadly.

So we'd probably need another #compdef switch to activate emulation
mode, and then go through all the completion functions to determine
which ones should have it.

} (we'd probably need to enter zsh emulation plus set a few options,
} rather than just set explicit options --- but note the property that
} if the emulation is the same we do allow option changes to propagate
} between functions, as at present)

I wonder if "the same" is the best comparison to make here.  As an
example, if I write

	emulate zsh -c 'doglob() { print * }'

it may not be my intention to prevent the extendedglob option from
being "passed down" from a calling context.  On the other hand

	emulate zsh -o no_extendedglob -c '...'

clearly means extendedglob should be forced off.  This would mean that
the behavior of non-sticky functions follows naturally -- when the set
of options turned on/off is empty, any/all options are "inherited".

However, that would mean storing not just the state of the options, but
the sense of how they arrived at that state, which is a lot of overhead.
And I guess the caller could sneak extendedglob through by doing

	emulate zsh -c 'setopt extendedglob; doglob'

because then the sticky bits are the same but I've changed extendedglob
after the fact.

} The argument in favour is the behaviour is easier to document because
} it's based on emulations, and the function behaviour is guaranteed
} wherever it's loaded or called, not just from somewhere under
} _main_complete

Hmm, maybe.  The function behavior would be guaranteed as long as you
didn't autoload those functions before compinit had a chance to do so.
But I suspect a lot of people autoload everything in $fpath, and that
at least some of them do so before calling compinit, particulary the
people who zcompile their entire function set.  So we'd still need to
perform all those setopts in _main_complete et al.

} (remember what got me into this was the fact that forcing _path_files
} to autoload outside the completion system gave an error).

Another potentially interesting question:  How should/does this interact
with zcompile?  For example the -U (noaliases) option is recorded in the
ZWC file, why shouldn't other option state be compilable, too?