zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: <zsh-workers@zsh.org>
Subject: Re: Unset “zle_bracketed_paste” .zshrc
Date: Tue, 28 Jan 2020 11:09:19 +0000	[thread overview]
Message-ID: <1580209759.6442.3.camel@samsung.com> (raw)
In-Reply-To: <1580133672.4960.15.camel@samsung.com>

On Mon, 2020-01-27 at 14:01 +0000, Peter Stephenson wrote:
> On Sun, 2020-01-26 at 00:45 +0000, Daniel Shahaf wrote:
>>> 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.

Duh.  We already have this --- "zmodload -Fa", and it's already
documented as fixing the problem that was bugging me --- don't
automatically load other features from the module as that can cause
unwanted side effects.  I'd completely forgotten implementing this.

% zmodload -Fa zsh/datetime p:EPOCHSECONDS
% print $EPOCHSECONDS
1580209515
% zmodload -Fl zsh/datetime
-b:strftime
+p:EPOCHSECONDS
-p:EPOCHREALTIME
-p:epochtime

This is another way of fixing the underlying problem --- e.g. here
you don't need to "unset EPOCHREALTIME" because it wasn't provided
as a feature in the first place.  You can turn on and off the
feature as needed once the module is loaded.

pws


  reply	other threads:[~2020-01-28 11:10 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
2020-01-27 14:01         ` Peter Stephenson
2020-01-28 11:09           ` Peter Stephenson [this message]
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=1580209759.6442.3.camel@samsung.com \
    --to=p.stephenson@samsung.com \
    --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).