From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21368 invoked from network); 16 May 2021 15:27:46 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 16 May 2021 15:27:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Transfer-Encoding: Content-Type:Subject:Cc:To:From:Date:References:In-Reply-To:Message-Id: Mime-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=5wPtSKY54dOsUxFbfA7XTx1dANTkVb+pTy7JU9vSFnU=; b=Veo5pgjT4kEpvRYj0fij1bc0B7 ZNjb5gcIVbj85QwltKPCXc9HHW9fNonkTtiPlbjcF61n/W8PZV+R+nG5ZrZ/D/iqFYjuqYamMvBCJ RR1b0NyhxMD8WCnH2SW+62yvTfwpPa35gOjq4lRySXXyeHCArnJvTOkQA0L4DlZy9PyFMtKlRx96H fDF2FgwJbxtUSMDVAqscODc+fBlm3en2vxVnlcXmoWjRviqwlLCSFSCqZTzVy9tvfSsvq8dYLmT8T epj+NG8vDb3xfiqW/tdHtwjKkDIYhTynoRu0lHK0sCN2Dtgi1Wio9yt5LOjB8qCJ+IDsyo40jx9AY LZiHVu9Q==; Received: from authenticated user by zero.zsh.org with local id 1liIgE-000Mdd-4c; Sun, 16 May 2021 15:27:46 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1liIfx-000ML7-2y; Sun, 16 May 2021 15:27:29 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailauth.nyi.internal (Postfix) with ESMTP id E6B5127C0054; Sun, 16 May 2021 11:27:27 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 16 May 2021 11:27:27 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeifedgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpefnrgif rhgvnhgtvggpgggvlhojiihquhgviicuoehlrghrrhihvhesiihshhdrohhrgheqnecugg ftrfgrthhtvghrnhepueefheelieekieejtdfggfetheehiedvtdeiudekjedvjefgjedu feekveelgfegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheplhgrrhhrhihvodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeh udekjeejtdegqdduudelvdejfeekhedqlhgrrhhrhihvpeepiihshhdrohhrghesfhgrsh htmhgrihhlrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 71013A00079; Sun, 16 May 2021 11:27:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416 Mime-Version: 1.0 Message-Id: <728024c4-9706-442d-b922-f12fa99e0ddf@www.fastmail.com> In-Reply-To: References: <7E71FA83-356E-448B-9726-02DF3FF5BD14@gmail.com> <873D08A9-F321-474A-8440-CCE7DCCBA529@gmail.com> <20210414120551.GA3882@tarpaulin.shahaf.local2> <20210415213456.GE6669@tarpaulin.shahaf.local2> Date: Sun, 16 May 2021 11:27:00 -0400 From: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= To: zsh-workers@zsh.org Cc: "Marlon Richert" Subject: =?UTF-8?Q?Re:_[RFC][PATCH]_Reset_ZLE_hooks_when_changing_prompt_themes_(?= =?UTF-8?Q?was_Re:_[RFC][PATCH]_`newuser`_prompt_theme)?= Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Seq: 48839 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Hi, Is workers/48609 ready to commit, or should Marlon make further changes, or...? vq On Wed, May 5, 2021, at 2:10 AM, Marlon Richert wrote: > On Sun, May 2, 2021 at 8:59 PM Bart Schaefer wrote: > > > > On Fri, Apr 16, 2021 at 3:38 PM Marlon Richert wrote: > > > > > > Attached is a new version of the patch that handles _all the thing= s._ \o/ > > > > This looks OK, with two questions: > > 1. Subshells have been introduced. Those won't be treated as > > interactive shells. >=20 > Are you sure about that? When I do `foo() { ( setopt ) }; foo`, it > still lists 'interactive' (though not 'monitor' or 'zle'). >=20 > > Does that matter? >=20 > It doesn't appear to matter. The prompt previews look the same as > before. Try `prompt -p` (without further args). Doesn >=20 > > 2. This bit in the restore style: > > + $( add-zsh-hook -L ) > > + $( add-zle-hook-widget -L ) > > There may not be anything to be done about this, but unless I'm > > mistaken that just re-adds all the previous hooks, it doesn't remove= > > any? The code it is replacing clobbered the entire list of precmd a= nd > > preexec hooks, which I suppose also might also be wrong if anything > > other than the prompt theme was manipulating them. >=20 > `add-zsh-hook -L` outputs statements in the form of `typeset -g -a > _functions=3D( ... )`, while `add-zle-hook-widget -L` > outputs statements in the form of `zstyle zle- widgets > : ...` (which is where add-zle-hook-widget stores the hook= > widgets to call internally). eval'ing either of these results in the > same good, old-fashioned clobbering as in the old code. So, no > functional change there. :) >=20 > I just realized, though, that these lines (new and old) don't actually= > do anything useful: > * When you call `prompt`, it will not unhook anything not called > `prompt_*_`. So, whatever hooks you've set up that don't follow > the naming scheme will still be there when you call `prompt restore`. > No need to restore them. > * When you call `prompt`, it will unhook everything called > `prompt_*_`. So, if a prompt theme correctly implements the > prompt system contract, its hook functions will already get unhooked > when switching themes. Again, no need to do anything special when > calling `prompt restore`. >=20 > The only case I can think of that would need special handling is if > you already had hooks installed that follow the `prompt_*_` > naming convention before calling `prompt` for the first time. >=20 > Should we just get rid of this part of the "restore" logic? And > instead just document clearly that `prompt` will auto-remove all hooks= > that follow its naming scheme? >=20 >=20 > And speaking of prompt hooks and naming schemes: >=20 > On Fri, Apr 16, 2021 at 12:34 AM Daniel Shahaf wrote: > > Marlon wrote on Thu, Apr 15, 2021 at 21:54:48 +0300: > > > On 14 Apr 2021, at 15:05, Daniel Shahaf w= rote: > > > >> +++ b/Functions/Prompts/promptinit > > > >> @@ -178,8 +177,13 @@ Use prompt -h for help on specific= themes.' > > > >> > > > >> # Reset some commonly altered bits to the default > > > >> local hook > > > >> - for hook in chpwd precmd preexec periodic zshaddhistory= zshexit; do > > > >> - add-zsh-hook -D "${hook}" "prompt_*_${hook}" > > > >> + for hook in chpwd precmd preexec periodic zshaddhistory= zshexit \ > > > >> + zsh_directory_name; do > > > >> + add-zsh-hook -D "$hook" "prompt_*_$hook" > > > >> + done > > > >> + for hook in isearch-exit isearch-update line-pre-redraw= line-init \ > > > >> + line-finish history-line-set keymap-select; do > > > >> + add-zle-hook-widget -D "$hook" "prompt_*_$hook" > > > > > > > > Recommend to name these prompt_${foo}_bar-{isearch-exit,isearch-= update,=E2=80=A6,keymap-select} > > > > for some fixed value of =C2=ABbar=C2=BB to avoid namespace issue= s (i.e., name > > > > collisions between existing prompts and future hooks). > > > > > > Wouldn=E2=80=99t that be a breaking change in the API, though? > > > > No, it wouldn't, because those are add-zle-hook-widget hooks and the= > > current API only deals with add-zsh-hook hooks. > > > > We could even recommend that add-zsh-hook hooks be named > > prompt_${foo}_baz_{chpwd,=E2=80=A6} for some fixed value of baz. We= don't even > > have to change the code to support this (because the asterisk will m= atch > > =C2=AB${foo}_baz=C2=BB just fine); we just need to document the reco= mmendation and > > deprecate the previous recommended naming pattern. > > > > > Also, isn=E2=80=99t the prefix prompt_${foo}_ already a namespace = of sorts? Why change this? > > > > What if the foo theme declares a function called prompt_foo_lorem (o= r > > even prompt_foo_ipsum_lorem) that _isn't_ an =C2=ABadd-*-hook lorem=C2= =BB hook > > function, and later we start to to auto-register functions matching = the > > name pattern? > > > > Or if we were to make =C2=ABadd-zsh-hook bar lorem=C2=BB and =C2=ABa= dd-zle-hook-widget > > bar ipsum=C2=BB both valid, for a single value of bar, and a prompt = theme > > wanted to install both hooks _and_ name the functions =C2=ABlorem=C2= =BB and =C2=ABipsum=C2=BB > > conventionally? > > > > Or if someone wanted to quickly grep for add-zle-hook-widget callbac= ks? >=20 > If we're going to change the prompt function naming scheme anyway, can= > we change it to something that starts with . or _? Because then > `zstyle ':completion:*' prefix-needed yes` will conveniently hide > these. >=20 > How about .prompt..? And then auto-register these > functions as hooks? >=20 > And should all of this go into the same patch? If `prompt` > automatically unregisters all hooks that follow a naming pattern > (regardless of how they've been registered), then I think it would > make sense for it to automatically register them, too. >=20 >=20