From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 7983d7f2 for ; Mon, 27 Jan 2020 14:02:06 +0000 (UTC) Received: (qmail 8554 invoked by alias); 27 Jan 2020 14:01:56 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45347 Received: (qmail 24885 invoked by uid 1010); 27 Jan 2020 14:01:56 -0000 X-Qmail-Scanner-Diagnostics: from mailout1.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25703. spamassassin: 3.4.2. Clear:RC:0(210.118.77.11):SA:0(-7.0/5.0):. Processed in 3.627343 secs); 27 Jan 2020 14:01:56 -0000 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.samsung.com designates 210.118.77.11 as permitted sender) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20200127140114euoutp0153315cfa98e0421666c0c9409ad10e12~twzRkviRG1539615396euoutp01m X-AuditID: cbfec7f4-0e5ff7000001ed07-40-5e2eed291758 Message-ID: <1580133672.4960.15.camel@samsung.com> Subject: Re: Unset =?UTF-8?Q?=E2=80=9Czle=5Fbracketed=5Fpaste=E2=80=9D?= .zshrc From: Peter Stephenson To: Date: Mon, 27 Jan 2020 14:01:12 +0000 In-Reply-To: <20200126004519.6e44ae68@tarpaulin.shahaf.local2> X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsWy7djP87qab/XiDB4cNrM42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGQc6/zMXTJCs2N19mrGBcYFIFyMnh4SAicSyi7+Zuxi5OIQE VjBKnL23BMrpY5Jov3aDBcLpZZI492ICG0zL1+6tbBCJ5YwS/f92IlTtOXiLEcI5wyjx9tYE qGEXGCVmbNzHCNLPK2AkcfrdOqYuRg4OYYFAiR2dyiBhNgFDiambZoOViAhISlxrPg1mswio Ssxe/5AdxOYUsJP42H4M6gwNiQ03jzFBjBSUODnzCQuIzSwgL9G8dTbYXgmBx2wStxoOMUI0 uEg0r+xmhbCFJV4d38IOYctI/N85nwmioZ1RYs2k1+wQTg+jxKajd6C6rSX6bl9kBLmaWUBT Yv0ufYiwo8TvqxPYQcISAnwSN94KQhzBJzFp23RmiDCvREebEES1msSOpq2MEGEZiadrFCYw Ks1C8sEsJB/MQli1gJF5FaN4amlxbnpqsVFearlecWJucWleul5yfu4mRmAyOP3v+JcdjLv+ JB1iFOBgVOLhPXBBL06INbGsuDL3EKMEB7OSCO89Hp04Id6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rzGi17GCgmkJ5akZqemFqQWwWSZODilGhhX2h/tFuiW0qraf21F1dLMs9ruYhseFz++u/jM l5shS1Q/Tr7016YzxLlsbVMwe2FsdDh3rVjzrXdMq53evi5Tn/j3wGajP8fdv9r6NHQ4hJ7m Z9DWso7wUdU37njWZVN2eZXyGZkEycP/Z62LdLIWqdqjxL8lf0H/zPRbu2s/r208fZ9Ps0yJ pTgj0VCLuag4EQDaOkznAgMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42I5/e/4XV3Nt3pxBic3y1scbH7I5MDoserg B6YAxig9m6L80pJUhYz84hJbpWhDCyM9Q0sLPSMTSz1DY/NYKyNTJX07m5TUnMyy1CJ9uwS9 jAOd/5kLJkhW7O4+zdjAuECki5GTQ0LAROJr91a2LkYuDiGBpYwSjyduZ4NIyEh8uvKRHcIW lvhzrQuqqJtJ4sH1WcwQzhlGia3vZ7NAOBcYJY7+fc0M0sIrYCRx+t06pi5GDg5hgUCJHZ3K IGE2AUOJqZtmM4LYIgKSEteaT4PZLAKqErPXPwTbxilgJ/Gx/RjUtgdMEu0fr4AVMQtoSrRu /w11kobEhpvHmCB2CUqcnPmEBaJGXqJ562zmCYxCs5C0zEJSNgtJ2QJG5lWMIqmlxbnpucWG esWJucWleel6yfm5mxiB4b/t2M/NOxgvbQw+xCjAwajEw3vggl6cEGtiWXFl7iFGCQ5mJRHe ezw6cUK8KYmVValF+fFFpTmpxYcYTYE+msgsJZqcD4zNvJJ4Q1NDcwtLQ3Njc2MzCyVx3g6B gzFCAumJJanZqakFqUUwfUwcnFINjO7/TNiZiyf2NvxNUsirqti8OOOu4UtrWZ2W//de2Ury XFoc05eXHegaLPR+hX8Po/vEk/7/VH5tZ8zZenpu16+42QxZdvwcnImSXy7nd1UxRb4/sPnm SrGJV5IY70x0MTqZa/p2Leev9Jd3vxn+q20UfGf4avOShXdPVRznlNB7e+XXb6kbUUosxRmJ hlrMRcWJAJy3dO+VAgAA X-CMS-MailID: 20200127140113eucas1p1a7a8462e7113a9fc4365a73b2f7b69ae X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20200123031354eucas1p1605fb92fcf91bd7e2f1b13677b6cc244 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200123031354eucas1p1605fb92fcf91bd7e2f1b13677b6cc244 References: <0723EF0A-BD62-4C2C-AAA1-735AD3D64768@icloud.com> <20200123031249.034c7e1a@tarpaulin.shahaf.local2> <1579773213.5343.1.camel@samsung.com> <20200126004519.6e44ae68@tarpaulin.shahaf.local2> 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.   > > 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