Re: off topic

Re: off topic

[Sebastian Gniazdowski]

Hello,
I've stumbled upon this 2016 post from Oliver. It is attached at the end. Let me share my 2-3 year experience about plugins:
- Plugin is: name.plugin.zsh sourced, $0:h added to $fpath.

So autoload functions will work and also completions, too. Such plugin manager will be very compact: a hopefully flexible git cloning code + sourcing.

The new 5.3.1-dev-0 functionality can be used to skip $fpath changes: autoloads via absolute paths. To do this, autoload() function to shadow the builtin should be added before sourcing, and it would catch user's autoload, and prepend $0:h. That's it. Nested, post-sourcing autoloads (i.e. catched "autoload X" from plugin.zsh, uncatched from within function X, at runtime) will work with the 5.3.1-dev-0 functionality.

It might sound heavy, but I shadow multiple things in Zplugin: zle, zstyle, bindkey, autoload, compdef and no problems occurred and no reports about this.

- Then goes the hidden truth about plugins, not easily discovered: plugins can call compdef, so compinit should be in place already (it defines compdef), but plugins extend $fpath.

Solution in Zplugin: compdefs are saved via shadowing compdef() function, and "zplugin cdreplay" command is provided for user, to be ran after he calls compinit, which is expected to be after all Zplugin invocations.

Solution in OMZ: plugins are given via array. OMZ can make all $fpath changes and invoke compinit before sourcing plugins, so compdef is ready to use for the plugins when sourcing them.

Possible solution: "zplugin load"-like call should append to some array, with some possible options, and then "plug apply" call would be expected from user, that would do $fpath changes, compinit and whole sourcing. That said, compdef shadowing is really nice looking and working thing, and it doesn't hide compinit somewhere in plugin manager.

- Small thing: plugins can be compiled at install, I do this from 1 year now with Zplugin, and no problems are reported. That said, other people are maybe able to squeeze milliseconds from this (heard that), but I saw no changes in loading time.

Now set of things that I plan for Zplugin after observing things for 1.4 year. I don't propose Zplugin because it's little verbose (but still rather fastest out there) with the reporting feature.

- I observed a trend to make plugin manager a swiss-knife. If you look at the first factoid I gave, then plugin manager is just clone+source. However, the swiss-knife trait can uplift this not-great state.

- Zplugin has "snippet" command, it kinda shows what's this is about: it creates directory that encodes url of a remote file:

github--DOT--com--SLASH--robbyrussell--SLASH--oh-my-zsh--SLASH--blob--SLASH--master--SLASH--lib--SLASH--git.zsh

then downloads the file into this directory, and sources it. This allows to use 99% of OMZ plugins without bloating code with OMZ-specific stuff, because 99% of plugins there are single file without autoloads. Following "snippet" commands will skip downloading. Note the advantage that this creates. You can easily update the snippet, hook it to remote location – a swiss-knife like thing resulting from simple concept.

- Such simple concepts allow clever zshrc. For example, how to load this non-plugin: https://github.com/trapd00r/LS_COLORS ? A Zplugin user did:

zplugin load trapd00r/LS_COLORS
LS_COLORS_DIR=$ZPLG_PLUGINS_DIR/trapd00r---LS_COLORS
if [[ ! $LS_COLORS_DIR/LS_COLORS.plugin.zsh -nt $LS_COLORS_DIR/LS_COLORS ]]; then
	dircolors -b $LS_COLORS_DIR/LS_COLORS > $LS_COLORS_DIR/LS_COLORS.plugin.zsh
	zplugin compile trapd00r/LS_COLORS
	source $LS_COLORS_DIR/LS_COLORS.plugin.zsh
fi

So he has single dircolors call in case of update, which is a serious asset, as author proposed doing "eval $( dircolors -b $HOME/LS_COLORS )", i.e. a fork, and eval usage probably slightly slower than source. So, a swiss-knife could be added for such fancy sourcing, that would be better than the "create plugin.zsh on -ot" user-side solution above.

- Such swiss-knife are also "hook-build" and "hook-load" in zplug/zplug (other plugin manager), which specify code to be ran after install/update and after loading.

- I can think of: option to trigger "git reset --hard HEAD" before update, and also doing "hook-build" that modifies or removes files. Compare this to normal zshrc management of things.

- "if" option, that would test "[[ some = condition ]]", and decide to load the plugin

I think this can be approached as tools for any not-conforming thing on github.

- One last thing – all my plugins do:

if [[ -z "$ZPLG_CUR_PLUGIN" && -z "${fpath[(r)$MY_REPO_DIR]}" ]]; then
    fpath+=( "$MY_REPO_DIR" )
fi

Basically, as it can be seen, plugin managers can be skipped because plugin can correctly manage $fpath itself. The official plugin manager could create standard $ZPLG_CUR_PLUGIN analogue, I would switch Zplugin to that standard parameter (indicating that plugin manager is active and no self-management of $fpath is needed).

Sebastian


On 10 Dec 2016 at 03:50:26, Oliver Kiddle wrote:
Rather than a source-able file, would it perhaps make sense to embrace
the concept of plugins.
It's a concept that people are familiar with from other software.
With vim for example, it is common to have a list in .vimrc, e.g:
  call plug#begin('~/.vim/plugged')
  Plug 'surround.vim'
  Plug 'tommcdo/vim-exchange'
  ...

The various existing zsh plugin managers are similar.

One well known plugin named sensible.vim is similar to what you
posted: defaults everyone can agree on.

I think it also tends to result in better maintained plugins when people
keep their own plugin in their own github area vs. an omz pull request
and then assuming that the omz people will look after it thereafter.

As a first step, we could add an Etc/plugin-guide file to outline
conventions such as how structure a plugin, use of add-zsh-hook,
how to avoid trampling on the rest of the user's setup. default_zstyle
could perhaps be included in Misc (or added as an option to zstyle).
Name of path variable which is used when searching for plugins, etc.
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.

We could include a rudimentary plugin manager. So people would do
something like:
  autoload -U pluginit; pluginit
  plug zsh-syntax-highlighting
  plug zsh-viexchange
Or they could continue using zplugin or whatever else if they want
fancy features like coloured github updates. And if we've kept
things simple, it could work to just source a single file for a
plugin.

Finally, we could include the odd plugin in the distribution for
anything which could be considered fairly core - such as the sensible
defaults plugin.

--
Sebastian Gniazdowski
psprint /at/ zdharma.org

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])
 

Re: off topic

[Yuri D'Elia]

On Fri, Dec 09 2016, Oliver Kiddle wrote:
> There's clear advantages to having a powerful setup that you understand
> well. If that process now involves "brutality" then you can understand
> why people might be be happy to just take what they get with oh-my-zsh:
> and I don't view that as heresy.

Maybe people seem to think that reading the actual [lengthy]
documentation is "brutality" ;)

I pretty much share the same views as Oliver on that front.
And I'm pretty sure this was discussed before.

But it can provide a showcase of features you might want to enable,
which is a good thing. Sometimes you don't know a feature existed until
you see it, as there are just too many of them. Plus, some people
really, _really_ like prompt-bling!

There are certainly zsh users out there that just want that, and are
fine with whatever TAB does by default.