From: "Lawrence Velázquez" <larryv@zsh.org>
To: zsh-workers@zsh.org
Cc: "Marlon Richert" <marlon.richert@gmail.com>
Subject: Re: [RFC][PATCH] Reset ZLE hooks when changing prompt themes (was Re: [RFC][PATCH] `newuser` prompt theme)
Date: Sun, 16 May 2021 11:27:00 -0400 [thread overview]
Message-ID: <728024c4-9706-442d-b922-f12fa99e0ddf@www.fastmail.com> (raw)
In-Reply-To: <CAHLkEDvAJJZUJNR0FJS98OUF0h8Rw0XY1LQqJiK41KQJe6BnZw@mail.gmail.com>
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 <schaefer@brasslantern.com> wrote:
> >
> > On Fri, Apr 16, 2021 at 3:38 PM Marlon Richert <marlon.richert@gmail.com> wrote:
> > >
> > > Attached is a new version of the patch that handles _all the things._ \o/
> >
> > This looks OK, with two questions:
> > 1. Subshells have been introduced. Those won't be treated as
> > interactive shells.
>
> Are you sure about that? When I do `foo() { ( setopt ) }; foo`, it
> still lists 'interactive' (though not 'monitor' or 'zle').
>
> > Does that matter?
>
> It doesn't appear to matter. The prompt previews look the same as
> before. Try `prompt -p` (without further args). Doesn
>
> > 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 and
> > preexec hooks, which I suppose also might also be wrong if anything
> > other than the prompt theme was manipulating them.
>
> `add-zsh-hook -L` outputs statements in the form of `typeset -g -a
> <hook>_functions=( <func> ... )`, while `add-zle-hook-widget -L`
> outputs statements in the form of `zstyle zle-<hook> widgets
> <nr>:<widget> ...` (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. :)
>
> 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_*_<hook>`. 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_*_<hook>`. 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`.
>
> The only case I can think of that would need special handling is if
> you already had hooks installed that follow the `prompt_*_<hook>`
> naming convention before calling `prompt` for the first time.
>
> 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?
>
>
> And speaking of prompt hooks and naming schemes:
>
> On Fri, Apr 16, 2021 at 12:34 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > Marlon wrote on Thu, Apr 15, 2021 at 21:54:48 +0300:
> > > On 14 Apr 2021, at 15:05, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > > >> +++ b/Functions/Prompts/promptinit
> > > >> @@ -178,8 +177,13 @@ Use prompt -h <theme> 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,…,keymap-select}
> > > > for some fixed value of «bar» to avoid namespace issues (i.e., name
> > > > collisions between existing prompts and future hooks).
> > >
> > > Wouldn’t 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,…} for some fixed value of baz. We don't even
> > have to change the code to support this (because the asterisk will match
> > «${foo}_baz» just fine); we just need to document the recommendation and
> > deprecate the previous recommended naming pattern.
> >
> > > Also, isn’t the prefix prompt_${foo}_ already a namespace of sorts? Why change this?
> >
> > What if the foo theme declares a function called prompt_foo_lorem (or
> > even prompt_foo_ipsum_lorem) that _isn't_ an «add-*-hook lorem» hook
> > function, and later we start to to auto-register functions matching the
> > name pattern?
> >
> > Or if we were to make «add-zsh-hook bar lorem» and «add-zle-hook-widget
> > bar ipsum» both valid, for a single value of bar, and a prompt theme
> > wanted to install both hooks _and_ name the functions «lorem» and «ipsum»
> > conventionally?
> >
> > Or if someone wanted to quickly grep for add-zle-hook-widget callbacks?
>
> 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.
>
> How about .prompt.<theme>.<hook>? And then auto-register these
> functions as hooks?
>
> 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.
>
>
next prev parent reply other threads:[~2021-05-16 15:27 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-13 19:41 [RFC][PATCH] `newuser` prompt theme Marlon
2021-04-13 20:31 ` Roman Perepelitsa
2021-04-13 20:44 ` Bart Schaefer
2021-04-14 5:09 ` Marlon Richert
2021-04-14 5:17 ` Bart Schaefer
2021-04-14 5:45 ` Marlon
2021-04-14 12:05 ` Daniel Shahaf
2021-04-14 13:17 ` Marlon
2021-04-14 14:09 ` Daniel Shahaf
2021-04-15 1:07 ` Bart Schaefer
2021-04-15 3:50 ` Marlon Richert
2021-04-15 20:27 ` Daniel Shahaf
2021-04-15 23:42 ` Daniel Shahaf
2021-04-15 11:11 ` Mikael Magnusson
2021-04-15 16:44 ` vcs_info's global variables (was: Re: [RFC][PATCH] `newuser` prompt theme) Daniel Shahaf
2021-04-16 16:04 ` [RFC][PATCH] `newuser` prompt theme Marlon
2021-04-16 17:13 ` Daniel Shahaf
2021-04-16 19:19 ` Marlon Richert
2021-04-16 19:30 ` Daniel Shahaf
2021-04-19 16:46 ` Marlon Richert
2021-05-02 17:18 ` Lawrence Velázquez
2021-05-03 2:38 ` Bart Schaefer
2021-05-03 4:11 ` Lawrence Velázquez
2021-05-03 11:38 ` [PATCH] Add customizable `vcs` prompt theme (was Re: [RFC][PATCH] `newuser` prompt theme) Marlon Richert
2021-05-09 18:04 ` Lawrence Velázquez
2021-05-31 1:01 ` Lawrence Velázquez
2021-06-09 12:58 ` Marlon Richert
2021-06-09 13:22 ` Roman Perepelitsa
2021-06-09 18:06 ` Marlon Richert
2021-06-10 9:30 ` Roman Perepelitsa
2021-06-10 13:47 ` Marlon Richert
2021-06-10 14:01 ` Marlon Richert
2021-06-10 17:45 ` Roman Perepelitsa
2021-06-20 22:13 ` Marlon Richert
2021-06-23 17:26 ` Roman Perepelitsa
2022-08-08 10:12 ` Marlon Richert
2022-08-08 10:17 ` Roman Perepelitsa
2021-04-14 14:09 ` sysexits.h codes? (was: " Daniel Shahaf
2021-04-30 19:40 ` Marlon Richert
2021-04-30 21:16 ` Daniel Shahaf
2021-04-30 21:34 ` Bart Schaefer
2021-05-01 15:09 ` Daniel Shahaf
2021-04-30 21:40 ` Bart Schaefer
2021-05-01 13:39 ` Marlon Richert
2021-05-01 14:43 ` Daniel Shahaf
2021-05-03 11:36 ` Marlon Richert
2021-05-03 16:04 ` Daniel Shahaf
2021-05-04 11:13 ` Marlon Richert
2021-05-21 11:38 ` Marlon Richert
2021-04-14 15:30 ` [RFC][PATCH] `newuser` prompt theme Arseny Maslennikov
2021-04-14 18:52 ` Daniel Shahaf
2021-04-14 14:00 ` precmd hooks and $? Bart Schaefer
2021-04-14 15:18 ` docs patches for precmd hooks and $?, and vcs_info Daniel Shahaf
2021-04-15 2:35 ` Bart Schaefer
2021-04-15 16:17 ` Archives render attachments as first-class messages (was: docs patches for precmd hooks and $?, and vcs_info) Daniel Shahaf
2021-04-15 18:54 ` [RFC][PATCH] Reset ZLE hooks when changing prompt themes (was Re: [RFC][PATCH] `newuser` prompt theme) Marlon
2021-04-15 21:34 ` Daniel Shahaf
2021-04-16 22:34 ` Marlon Richert
2021-04-25 16:08 ` Lawrence Velázquez
2021-05-02 17:03 ` Lawrence Velázquez
2021-05-02 17:59 ` Bart Schaefer
2021-05-05 6:10 ` Marlon Richert
2021-05-16 15:27 ` Lawrence Velázquez [this message]
2021-05-16 19:31 ` Marlon Richert
2021-05-17 4:19 ` Bart Schaefer
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=728024c4-9706-442d-b922-f12fa99e0ddf@www.fastmail.com \
--to=larryv@zsh.org \
--cc=marlon.richert@gmail.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).