Re: Unset “zle_bracketed_paste” .zshrc

[Peter Stephenson <p.stephenson@samsung.com>]

On Sun, 2020-01-26 at 00:45 +0000, Daniel Shahaf wrote:
> > The obvious expected behaviour would be for it to have the same
> > behavious as unsetting the parameter after the module is loaded.  But a
> > quick tests suggests that doesn't work for readonly parameters, for one
> > --- all that would happen is that would produce an error when the module
> > is loaded, which doesn't really make much sense.
> In what case would an error happen upon loading of the module?
>
> The only error I see is this:
> 
>     % zsh -fc 'unset builtins; zmodload zsh/parameter'
>     %
> 
>     % zsh -fc 'zmodload zsh/parameter; unset builtins' 
>     zsh:1: read-only variable: builtins
>     zsh: exit 1     zsh -fc 'zmodload zsh/parameter; unset builtins'
>     % 
> 
> And I think it makes sense, because trying to unset a non-autoloadable
> readonly parameter gives the same error.

The worry is simply that this happens on any autoload to that module,
which may be triggered by a completely different parameter; you then see
this message about a parameter that's got nothing to do with the
operation that's actually taking place.

So if does what you expect, so long as you don't expect it to be
seamless and with no possible confusion :-).

> > [...] The autoload flag effective means the parameter behaviour defers to
> > the module.
> In other words, the rule is a parameter should only be unset by
> explicitly calling the «unset» builtin; loading and unloading the module
> doesn't affect the parameter's existence.  Thanks, this makes sense.
> 
> How about the following spec? —

Those look sensible --- which I think is all we can ask for, I don't see
any hard and fast rules coming down from on high.  <Peers quickly upwards>

> > Documenting the current behaviour is perfectly respectable.
> We could do this for 5.8, 
> but I'd like to take a shot at the
> general case too.  (Though I already have a backlog of patches I want to
> finish, or in some cases start.)

I'm not going to argue, either way.

> > Remember, you can use zmodload -F to manipulate which features
> > are provided by a module, although not at the point of declaring
> > autoloads --- some sort of autoloadable feature set might be another
> > way of doing this.
> How do you envision this working?  Would there be, say, a zmodload flag
> to add/remove entries from the default set of autofeatures?  Or would
> «unset options» implicitly twiddle the autofeatures metadata for the
> (not-yet-loaded) zsh/parameter module?

I'd start by simply add the interface to zmodload itself, in the first
instances.  That's already quite a job and not clear how useful it is.
At the moment, until you can read the feature set from the module you're
just guessing what the module provides.  The obvious fix is simply let
the user claim e.g. module zsh/foo provides p:bar and complain if it
doesn't when the module is loaded.

Any consequent interaction between parameter- or other feature-specific
code would then be a further issue on top of that.  So if the above
already looks a bit clunky, we can bury this idea.

pws