Re: completion files sensitive to user options like RC_QUOTES

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 6,  6:29pm, Oliver Kiddle wrote:
} Subject: Re: completion files sensitive to user options like RC_QUOTES
}
} Bart wrote:
} > The intention is that completion files will be auto-loaded from the
} > completion system after _main_complete has started, where they will be
} > affected by the set of options that it controls.
} 
}   _comp_options+=( NO_rcquotes )
}   foo '<tab> -> 'don'\''t'

OK, that's a reasonable counter-argument to my patch.

} In the early days, _comp_options was intentionally kept minimal.
} It contains a lot more than it used to so I worry that we've already
} broken things in some areas.

There would be a case for wrapping the "eval" expressions in _expand
with temporary restoration of $_comp_caller_options, because of the
effects of NO_ksharrays etc.  There might be a few other similar
situations.

} The quoting is internal to the C code so shouldn't look at
} _comp_caller_options. We'd need to add some sort of hook

We have the "sticky emulation" mechanism.  Entry to completion could
save the current option state before invoking the user-defined code,
and then compadd could temporarily revert to that saved state.  We
could also add another builtin (compopts?) to manage it explicitly,
though the state would still need initial capture.

On a side note, maybe we need a special keyword for "emulate" that
means "make sticky whatever the current options are" -- right now
you would have to spell that out explicitly, relative to some base
emulation such as zsh or sh.