From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: Re: Unset “zle_bracketed_paste” .zshrc
Date: Sun, 26 Jan 2020 00:45:18 +0000 [thread overview]
Message-ID: <20200126004519.6e44ae68@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <1579773213.5343.1.camel@samsung.com>
[ 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
next prev parent reply other threads:[~2020-01-26 0:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-17 23:20 Andrew Reyes
2020-01-18 19:40 ` Daniel Shahaf
2020-01-23 3:12 ` Daniel Shahaf
2020-01-23 9:53 ` Peter Stephenson
2020-01-26 0:45 ` Daniel Shahaf [this message]
2020-01-27 14:01 ` Peter Stephenson
2020-01-28 11:09 ` Peter Stephenson
2020-01-29 11:23 ` Peter Stephenson
2020-02-06 12:40 ` Daniel Shahaf
2020-02-06 13:32 ` Mikael Magnusson
2020-02-06 14:09 ` Peter Stephenson
2020-03-14 3:28 ` Daniel Shahaf
2020-01-29 8:34 ` Daniel Shahaf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200126004519.6e44ae68@tarpaulin.shahaf.local2 \
--to=d.s@daniel.shahaf.name \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).