Plugin conventions (was zsh-users Re: off topic)

Plugin conventions (was zsh-users Re: off topic)

[Bart Schaefer]

On Dec 11,  4:32am, Daniel Shahaf wrote:
} Subject: Re: off topic
}
} Oliver Kiddle wrote on Sat, Dec 10, 2016 at 03:50:26 +0100:
} > The omz convention seems to be a single file with the extension
} > .plugin.zsh which is sourced but there may be more to it than that.
} > We also need to think about the order in which commands are run.
} 
} Whatever convention we come up with, can we please arrange for the
} plugin's code to be parsed without user options and/or aliases in
} effect?

Sebastian's plugin manager goes to quite some lengths to handle this,
as I recall, including keeping deltas of the option changes so that
any option changes made by the plugin are preserved.

An outline of a simplistic approach to same (I like using zstyle to
avoid having to invent safe parameter names):

    {
      zstyle plugin-manager user-options "${(kv)options[@]}"
      zstyle plugin-manager user-aliases "${(kv)aliases[@]}"
      emulate -R zsh
      noglob unalias -m *
      if source some.plugin.zsh
      then
        zstyle plugin-manager some.plugin-options "${(kv)options[@]}"
        zstyle plugin-manager some.plugin-aliases "${(kv)aliases[@]}"
      fi
    } always {
      zstyle -a plugin-manager user-options options
      zstyle -a plugin-manager user-aliases aliases
      # ... and then merge in the deltas ...
    }

Another tricky bit is that the plugin might want to know what the
user's options were, so would have to be aware of how the plugin
manager has saved them.

Re: off topic

[Peter Stephenson]

On Fri, 9 Dec 2016 19:24:06 +0000
Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>     % env -i ZDOTDIR=$(mktemp -d) zsh
>     This is the Z Shell configuration function for new users,
>     zsh-newuser-install.
>     ⋮
>     (2)  Populate your /tmp/tmp.Z4bUNG8Gz5/.zshrc with the configuration recommended
>          by the system administrator and exit (you will need to edit
>          the file by hand, if so desired).
>     
>     --- Type one of the keys in parentheses --- 
> 
> Typing "2" creates a .zshrc with reasonable default settings, and drops
> the user to the prompt; no further menu choices.  The catch is that that
> check is hardcoded to inspect /etc/zsh/newuser.zshrc.recommended; that
> is, it ignores configure's --prefix.
> 
> So if we could make that check honour @PREFIX@, and ship a "recommended
> zshrc" that is less minimal than the default no-zshrc behaviour...
> I think that'd be a good step forward.

At the time there was a reason why newuser stuff used a fixed path
rather than tracking every version of the package, but not necessarily a
good one --- since the vast majority of users now will be receiving
things via a distribution it doesn't really apply.

My experience with recommended settings in previous threads (the last
one petered out some time ago now) is much like Gladstone's with the
Irish Question --- every time you think you're getting close, they
change the question(*).  But if you or anyone wants to pursue this further,
which I will happily support in the distribution, you might want
something like the following (untested --- and in particular untested
with out-of-tree configure which might make a difference).

pws

(*) You'll need to add "1066 and all that" to the search for
[de?]mystification on the subject.

commit 463a58ded82d3371b969bf9ee1b04814464d91bd
Author: Peter Stephenson <p.w.stephenson@ntlworld.com>
Date:   Fri Dec 9 21:24:37 2016 +0000

    Make recommended zshrc location configurable.

diff --git a/Functions/Newuser/zsh-newuser-install b/Functions/Newuser/zsh-newuser-install
index e4028fd..f639b6f 100644
--- a/Functions/Newuser/zsh-newuser-install
+++ b/Functions/Newuser/zsh-newuser-install
@@ -9,11 +9,29 @@ setopt extendedglob nonomatch warncreateglobal
 
 # How the function will be referred to.
 local myname=zsh-newuser-install
+integer force
+
+if [[ $1 = -f ]]; then
+  (( force = 1 ))
+  shift
+fi
+if [[ $1 = - || $1 == -- ]]; then
+  shift
+fi
+local zshrc_rec=/etc/zsh/newuser.zshrc.recommended
+if [[ -n $1 ]]; then
+  if [[ $1 = /* ]]; then
+    zshrc_rec=$1
+  else
+    print "Usage: $0 [ -f ] [ /path/to/newuser.zshrc.recommened ]" >&2
+    return 1
+  fi
+fi
 
 # Quick test not requiring any setting up.
 # Don't run if we're root.  (These variables are provided by the shell.)
 if (( EUID == 0 || UID == 0 )); then
-  if [[ $1 = -f ]]; then
+  if (( force )); then
     print -r "$myname: won't run as root.  Read the manual." >&2
   fi
   return 1
@@ -96,7 +114,7 @@ fi
 # if this really is a new user this probably isn't the right
 # time for screeds of explanation.
 if [[ ! -w $zd ]]; then
-  if [[ $1 = -f ]]; then
+  if (( force )); then
     print -r "$myname: can't write to $zdmsg." >&2
   fi
   return 1
@@ -104,7 +122,7 @@ fi
 
 # Don't run unless we can talk to the user.
 if [[ ! -t 0 || ! -t 1 ]]; then
-  if [[ $1 = -f ]]; then
+  if (( force )); then
     print -r "$myname: can only be used interactively." >&2
   fi
   return 1
@@ -115,7 +133,7 @@ if (( ${LINES:-0} < 15 || ${COLUMNS:-0} < 72 )); then
   return 1
 fi
 
-if [[ $1 != -f ]]; then
+if (( ! force )); then
   # The zsh/newuser module already tests for the following, so this test only
   # triggers if zsh-newuser-install is run by hand.
   if [[ -e $zd/.zshenv || -e $zd/.zprofile || \
@@ -934,7 +952,7 @@ fi
 
 
 # skip initial screen if the function was deliberately run by the user.
-if [[ $1 != -f ]]; then
+if (( ! force )); then
   clear
   print -r "This is the Z Shell configuration function for new users,
 $myname.
@@ -954,7 +972,7 @@ You can:
   print -r "
 (1)  Continue to the main menu.
 "
-  if [[ -f /etc/zsh/newuser.zshrc.recommended ]]; then
+  if [[ -f $zshrc_rec ]]; then
     print -r "(2)  Populate your $zdmsg/.zshrc with the configuration recommended
      by the system administrator and exit (you will need to edit
      the file by hand, if so desired).
@@ -978,14 +996,14 @@ You can:
     ;;
 
     (2)
-    cp /etc/zsh/newuser.zshrc.recommended $zd/.zshrc
+    cp $zshrc_rec $zd/.zshrc
     source $zd/.zshrc
     return 0
     ;;
 
     (*)
     print -r "Aborting."
-    if [[ $1 != -f ]]; then
+    if (( ! force )); then
       print "\
 The function will be run again next time.  To prevent this, execute:
   touch $zdmsg/.zshrc"
@@ -1036,7 +1054,7 @@ ${install_state[options]:+  ($install_state[options].)}
 (a)  Abort all settings and start from scratch.  Note this will overwrite
      any settings from $myname already in the startup file.
      It will not alter any of your other settings, however."
-  if [[ $1 = -f ]]; then
+  if (( force )); then
     print -r "
 (q)  Quit and do nothing else."
   else
@@ -1078,7 +1096,7 @@ ${install_state[options]:+  ($install_state[options].)}
     elif [[ ! -f $zd/.zshrc ]]; then
       print -r $msg >$zd/.zshrc
     fi
-    if [[ $1 != -f ]]; then
+    if (( force )); then
       print -r "The function will not be run in future, but you can run
 it yourself as follows:
   autoload -Uz $myname
diff --git a/Scripts/.gitignore b/Scripts/.gitignore
new file mode 100644
index 0000000..c889ba7
--- /dev/null
+++ b/Scripts/.gitignore
@@ -0,0 +1 @@
+newuser
diff --git a/Scripts/newuser b/Scripts/newuser
deleted file mode 100644
index b5d7421..0000000
--- a/Scripts/newuser
+++ /dev/null
@@ -1,8 +0,0 @@
-# zsh script sourced at startup when a user is found to have
-# no startup files.  See the documentation for the zsh/newuser
-# module in zshmodules(1).
-
-if functions zsh-newuser-install >/dev/null 2>&1 ||
-   autoload -U +X zsh-newuser-install; then
-   zsh-newuser-install
-fi
diff --git a/Scripts/newuser.in b/Scripts/newuser.in
new file mode 100644
index 0000000..678d115
--- /dev/null
+++ b/Scripts/newuser.in
@@ -0,0 +1,13 @@
+# zsh script sourced at startup when a user is found to have
+# no startup files.  See the documentation for the zsh/newuser
+# module in zshmodules(1).
+
+zshrc_rec=@zshrc_rec@
+if [[ -z $zshrc_rec ]]; then
+   prefix=@prefix@
+   zshrc_rec=@sysconfdir@/zsh/newuser.zshrc.recommended
+fi
+if functions zsh-newuser-install >/dev/null 2>&1 ||
+   autoload -U +X zsh-newuser-install; then
+   zsh-newuser-install $zshrc_rec
+fi
diff --git a/configure.ac b/configure.ac
index 920c2fc..55d3acd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -237,11 +237,22 @@ if test "x$zlogout" != xno; then
   AC_DEFINE_UNQUOTED(GLOBAL_ZLOGOUT, "$zlogout")
 fi
 
+AC_ARG_ENABLE(zshrc-rec,
+AC_HELP_STRING([-enable-zshrc-rec=FILE], [the full pathname of a recommended zshrc file for new users]),
+[zshrc_rec="$enableval"],
+[if test "x$etcdir" = xno; then
+  zshrc_rec=no
+else
+  zshrc_rec="$etcdir/zsh/newuser.zshrc.recommended"
+fi])
+dnl zshrc_rec is only used by a script and is not needed in the source.
+
 AC_SUBST(zshenv)dnl
 AC_SUBST(zshrc)dnl
 AC_SUBST(zprofile)dnl
 AC_SUBST(zlogin)dnl
 AC_SUBST(zlogout)dnl
+AC_SUBST(zshrc_rec)dnl
 
 dnl Do you want dynamically loaded binary modules.
 ifdef([dynamic],[undefine([dynamic])])dnl
@@ -3283,7 +3294,7 @@ AC_SUBST_FILE(DEFS_MK)dnl
 AC_SUBST_FILE(VERSION_MK)dnl
 
 AC_CONFIG_FILES(Config/defs.mk Makefile Doc/Makefile Etc/Makefile \
-Src/Makefile Test/Makefile)
+Src/Makefile Test/Makefile Scripts/newuser)
 AC_CONFIG_COMMANDS([config.modules], [. ./config.modules.sh])
 AC_CONFIG_COMMANDS([stamp-h], [echo >stamp-h])
 

plugin conventions (Re: off topic)

[Oliver Kiddle]

On 9 Dec, Bart wrote:
> On Dec 10,  3:50am, Oliver Kiddle wrote:
> }
> } Rather than a source-able file, would it perhaps make sense to embrace
> } the concept of plugins.
>
> If we're going that route, the plugin manager that Sebastian has been
> asking us for advice about for the last several months might be an
> interesting idea.

It's certainly an option to take an existing plugin manager and without
having looked into any of them, I would tend to assume that Sebastian's
is the best. It is also clearly very feature rich.

I used the wording "rudimentary plugin manager" because what I had
in mind foremost is standardising the conventions. A basic reference
implementation helps with documenting that and determining what issues
there might be. But perhaps that's already known. For example, I seem
to remember something about the various frameworks causing compinit to
be run multiple times. A pure plugin manager has no business running
compinit even once but if there is a fundamental reason such as needing
to do something only after compinit has run then perhaps we could add a
hook in to compinit. Or was a good solution found for zplugin?

> Although the idea with this particular file was simply to fold it in to
> compinit.

default_zstyle() doesn't prevent it altering an existing user's setup so
unconditional inclusion might be a problem.

Oliver

Re: plugin conventions (Re: off topic)

[Bart Schaefer]

On Dec 14,  1:40pm, Oliver Kiddle wrote:
} 
} It's certainly an option to take an existing plugin manager and without
} having looked into any of them, I would tend to assume that Sebastian's
} is the best. It is also clearly very feature rich.

He does appear to have taken the practices of a number of other more
rudimentary plugin managers into account as well as going to a lot of
effort to shield plugins from each other.

} I used the wording "rudimentary plugin manager" because what I had
} in mind foremost is standardising the conventions. A basic reference
} implementation helps with documenting that and determining what issues
} there might be. But perhaps that's already known.

If there's anything Sebastian hasn't thought of yet, I haven't thought
of it either :-) but then again I missed "printf -" for a year.

} For example, I seem
} to remember something about the various frameworks causing compinit to
} be run multiple times. A pure plugin manager has no business running
} compinit even once

The plugins themselves were running "compinit" to force their supplied
completion files to be found after updating fpath.  The manager resolves
this by adding a dummy compinit that queues up all the other attempted
runs until the user is ready to ask for them.

} > Although the idea with this particular file was simply to fold it in to
} > compinit.
} 
} default_zstyle() doesn't prevent it altering an existing user's setup so
} unconditional inclusion might be a problem.

That's true, though it avoids altering any directly conflicting setup.
We'd want a way to ask that the defaults not be included, just like we
have a way to skip "compaudit".