Re: Unset “zle_bracketed_paste” .zshrc

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

[ Sorry for the delay; I wanted to sleep on this before sending. ]

Peter Stephenson wrote on Thu, 23 Jan 2020 09:53 +0000:
> On Thu, 2020-01-23 at 03:12 +0000, Daniel Shahaf wrote:
> > I haven't tried to implement this yet, but what I have in mind is
> > (1) Make unsetparam_pm() add the PM_UNSET bit if the PM_AUTOLOAD bit is
> > present; (2) Make module loading, before creating a parameter, check if
> > there's a Param with PM_UNSET and PM_AUTOLOAD both set; if there is,
> > rather than create the "real" parameter, delete the tombstone parameter.
> > (But if there isn't a Param at all, the module _should_ create its special
> > Param anyway, to allow modules to be unloaded and reloaded in the same
> > shell session.)  
> 
> 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.

> So in that case, at least, the behaviour above is as logical as
> anything.
> 
> [...] 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? —

[[[
diff --git a/Test/V01zmodload.ztst b/Test/V01zmodload.ztst
index 1bd8c1900..854e21da0 100644
--- a/Test/V01zmodload.ztst
+++ b/Test/V01zmodload.ztst
@@ -348,6 +348,47 @@
 ?(eval):6: unknown function: systell
 ?(eval):9: file descriptor out of range
 
+ $ZTST_testdir/../Src/zsh -fc '
+   if zmodload -e zsh/parameter; then zmodload -u zsh/parameter; fi
+   unset options
+   zmodload zsh/parameter
+   echo $+options
+ '
+-f:can unset a non-readonly autoloadable parameter before loading the module
+>0
+# Currently prints '1'.
+
+ $ZTST_testdir/../Src/zsh -fc '
+   zmodload zsh/parameter
+   unset options
+   echo $+options
+ '
+0:can unset a non-readonly autoloadable parameter after loading the module
+>0
+
+ $ZTST_testdir/../Src/zsh -fc '
+   if zmodload -e zsh/parameter; then zmodload -u zsh/parameter; fi
+   unset builtins
+ '
+-f:can't unset a readonly autoloadable parameter before loading the module
+*?zsh:?: read-only variable: builtins
+# Currently, the 'unset' succeeds.
+
+ $ZTST_testdir/../Src/zsh -fc '
+   zmodload zsh/parameter
+   unset builtins
+ '
+1:can't unset a readonly autoloadable parameter after loading the module
+?zsh:3: read-only variable: builtins
+
+ $ZTST_testdir/../Src/zsh -fc '
+   zmodload zsh/parameter
+   zmodload -u zsh/parameter
+   echo $options
+ '
+0:unloading a module doesn't implicitly unset autoloadable parameters
+*>(on|off) *
+
 %clean
 
  eval "$deps"
]]]

(Note that two of the five cases currently fail.)

> 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.)

> 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?

Thanks,

Daniel