* Re: off topic [not found] ` <62522.1481300922__19313.1602755331$1481301401$gmane$org@hydra.kiddle.eu> @ 2016-12-09 20:12 ` Yuri D'Elia 0 siblings, 0 replies; 6+ messages in thread From: Yuri D'Elia @ 2016-12-09 20:12 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <62522.1481300922@hydra.kiddle.eu>]
[parent not found: <584AEDBF.2050402__19991.0537027337$1481307418$gmane$org@eastlink.ca>]
[parent not found: <20161209192406.GA27532@fujitsu.shahaf.local2>]
* Re: off topic [not found] ` <20161209192406.GA27532@fujitsu.shahaf.local2> @ 2016-12-11 18:06 ` Peter Stephenson 0 siblings, 0 replies; 6+ messages in thread From: Peter Stephenson @ 2016-12-11 18:06 UTC (permalink / raw) To: Zsh hackers list 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]) ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <584AEDBF.2050402@eastlink.ca>]
[parent not found: <161209165454.ZM9226@torch.brasslantern.com>]
[parent not found: <95362.1481338226__15466.9970310808$1481338718$gmane$org@hydra.kiddle.eu>]
[parent not found: <20161211043221.GA11489@fujitsu.shahaf.local2>]
* Plugin conventions (was zsh-users Re: off topic) [not found] ` <20161211043221.GA11489@fujitsu.shahaf.local2> @ 2016-12-11 9:29 ` Bart Schaefer 0 siblings, 0 replies; 6+ messages in thread From: Bart Schaefer @ 2016-12-11 9:29 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <95362.1481338226@hydra.kiddle.eu>]
[parent not found: <161209191323.ZM9548@torch.brasslantern.com>]
* plugin conventions (Re: off topic) [not found] ` <161209191323.ZM9548@torch.brasslantern.com> @ 2016-12-14 12:40 ` Oliver Kiddle 2016-12-14 23:51 ` Bart Schaefer 0 siblings, 1 reply; 6+ messages in thread From: Oliver Kiddle @ 2016-12-14 12:40 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: plugin conventions (Re: off topic) 2016-12-14 12:40 ` plugin conventions (Re: " Oliver Kiddle @ 2016-12-14 23:51 ` Bart Schaefer 0 siblings, 0 replies; 6+ messages in thread From: Bart Schaefer @ 2016-12-14 23:51 UTC (permalink / raw) To: zsh-workers 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". ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: off topic @ 2017-04-27 15:43 Sebastian Gniazdowski 0 siblings, 0 replies; 6+ messages in thread From: Sebastian Gniazdowski @ 2017-04-27 15:43 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-04-27 15:54 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20161209122958.GD19559@256bit.org> [not found] ` <57127.1481294647@hydra.kiddle.eu> [not found] ` <584AC8AC.9050406@eastlink.ca> [not found] ` <62522.1481300922__19313.1602755331$1481301401$gmane$org@hydra.kiddle.eu> 2016-12-09 20:12 ` off topic Yuri D'Elia [not found] ` <62522.1481300922@hydra.kiddle.eu> [not found] ` <584AEDBF.2050402__19991.0537027337$1481307418$gmane$org@eastlink.ca> [not found] ` <20161209192406.GA27532@fujitsu.shahaf.local2> 2016-12-11 18:06 ` Peter Stephenson [not found] ` <584AEDBF.2050402@eastlink.ca> [not found] ` <161209165454.ZM9226@torch.brasslantern.com> [not found] ` <95362.1481338226__15466.9970310808$1481338718$gmane$org@hydra.kiddle.eu> [not found] ` <20161211043221.GA11489@fujitsu.shahaf.local2> 2016-12-11 9:29 ` Plugin conventions (was zsh-users Re: off topic) Bart Schaefer [not found] ` <95362.1481338226@hydra.kiddle.eu> [not found] ` <161209191323.ZM9548@torch.brasslantern.com> 2016-12-14 12:40 ` plugin conventions (Re: " Oliver Kiddle 2016-12-14 23:51 ` Bart Schaefer 2017-04-27 15:43 off topic Sebastian Gniazdowski
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).