zsh-workers
 help / color / mirror / Atom feed
* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
@ 2021-04-05 19:44 Mikael Magnusson
  2021-04-05 21:01 ` Mikael Magnusson
                   ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: Mikael Magnusson @ 2021-04-05 19:44 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On 4/5/21, Marlon Richert <marlon.richert@gmail.com> wrote:
> On Thu, Mar 25, 2021 at 3:15 AM Daniel Shahaf <d.s@daniel.shahaf.name>
> wrote:
> I got replies so far from openSUSE and Fedora, and made some minor
> changes based on their feedback:
> https://gitlab.com/marlonrichert/zsh-sensible/-/commit/b111f20b14891af4a385b3867fe690dc8281fe8f

I didn't look at this before, so I'll have a go now...

> #
> # Type `zrestart` to safely apply changes after editing this file.
> #
> zrestart() {
>   local zshrc=${ZDOTDIR:-$HOME}/.zshrc
>   print -P "Validating %U$zshrc%u..."
>   zsh -nf $zshrc ||
>     return
>
>   print -P 'Restarting Zsh...'
>   zsh -l &&
>     exit
> }

This could be an autoloadable function, not pasted verbatim in .zshrc.
Also disagree with -l here. You can use $options[login] or $- to see
if you're in a login shell already and start same. Things like this we
can't fix after users already copy this config. It should try to
mostly be configuration, not helper functions that can have permanent
flaws once installed.

> ##
> # History settings
> # See http://zsh.sourceforge.net/Doc/Release/Parameters.html#Parameters-Used-By-The-Shell
> # and http://zsh.sourceforge.net/Doc/Release/Options.html#History
> #
>
> # File in which to save command line history
> HISTFILE=${ZDOTDIR:-$HOME}/.zhistory
>
> SAVEHIST=10000                  # Max number of history lines to save to file
> HISTSIZE=$(( 1.2 * SAVEHIST ))  # Max number of history lines to keep in memory
> setopt EXTENDED_HISTORY         # Save each command's time & duration to history.
> setopt INC_APPEND_HISTORY_TIME  # Save history whenever a command finishes, not just on shell exit.
> setopt HIST_EXPIRE_DUPS_FIRST   # Delete duplicate history lines first, when running out of space.
> setopt HIST_IGNORE_DUPS         # Don't store last command line if identical to previous one.

ok, I don't agree with the dups settings but they're changeable easily.

> ##
> # Prompt settings
> # See http://zsh.sourceforge.net/Doc/Release/Prompt-Expansion.html#Expansion-of-Prompt-Sequences
> # and http://zsh.sourceforge.net/Doc/Release/Parameters.html#Parameters-Used-By-The-Shell
> #
[snip]

This is 70 lines that should be a prompt theme, not pasted verbatim in .zshrc.

> ##
> # Key bindings
> # See http://zsh.sourceforge.net/Doc/Release/Zsh-Line-Editor.html#Zle-Builtins
> #
>
> bindkey -e      # Use `emacs` as the main keymap.
> typeset -A key  # Declare `$key` table, without overriding any existing values.

How could $key possibly already exist as an associative array at this
point? The shell just started so it could at most be a scalar from the
environment in which case you did just override it.

> # Check if the terminal supports setting application mode.
> zmodload zsh/terminfo
> autoload -Uz add-zle-hook-widget
> if [[ -n "$terminfo[smkx]" ]]; then
>   # Enable application mode, so we can use terminfo codes.
>   add-zle-hook-widget line-init .zshrc.app-mode; .zshrc.app-mode() { echoti smkx }
>   if [[ -n "$terminfo[rmkx]" ]]; then
>     add-zle-hook-widget line-finish .zshrc.raw-mode; .zshrc.raw-mode() { echoti rmkx }
>   fi
>
>   # Assign each value only if it has not been defined earlier.
>   : ${key[Up]:=$terminfo[kcuu1]}    ${key[Down]:=$terminfo[kcud1]}
>   : ${key[Right]:=$terminfo[kcuf1]} ${key[Left]:=$terminfo[kcub1]}
>   : ${key[End]:=$terminfo[kend]}    ${key[Home]:=$terminfo[khome]}
>   : ${key[PageUp]:=$terminfo[kpp]}  ${key[PageDown]:=$terminfo[knp]}
>   : ${key[Return]:=$terminfo[cr]}   ${key[Delete]:=$terminfo[kdch1]}
>   : ${key[Tab]:=$terminfo[ht]}      ${key[Backtab]:=${terminfo[kcbt]:-$terminfo[cbt]}}
> fi
>
> # Fill in any remaining blank values with common defaults.
> : ${key[Up]:='^[[A'}   ${key[Down]:='^[[B'}    ${key[Right]:='^[[C'}   ${key[Left]:='^[[D'}
> : ${key[End]:='^[[F'}  ${key[Home]:='^[[H'}    ${key[PageUp]:='^[[5~'} ${key[PageDown]:='^[[6~'}
> : ${key[Return]:='\r'} ${key[Delete]:='^[[3~'} ${key[Tab]:='^I'}       ${key[Backtab]:='^[[Z'}

All of the above can be simple assignments given the previous comment.
I also personally don't like the smkx stuff but I guess that's just my
opinion not a criticism. It means you can't just look at what a
keycode is by using cat to make a keybind.

> # Alt-H: Open `man` page of current command.
> unalias run-help 2>/dev/null; autoload -Uz run-help{,-git,-ip,-openssl,-p4,-sudo,-svk,-svn}
>
> # Alt-Shift-/: Show definition of current command.
> unalias which-command 2>/dev/null; autoload -Uz which-command; zle -N which-command
>
> bindkey '^Z'    undo  # Control-Z
> bindkey '^[^Z'  redo  # Alt-Control-Z
>
> # Up/Down: Cycle through history lines that start with same word as command line.
> zle -A up-line-or-{search,history}
> zle -A down-line-or-{search,history}

These two lines don't actually bind any keys, but the comment claims they do.

> # Alt-Right/Left: Move cursor right/left one word.
> bindkey "^[$key[Right]" forward-word
> zle -A {emacs-,}forward-word
> bindkey "^[$key[Left]" backward-word
> zle -A {emacs-,}backward-word
> WORDCHARS=''  # Characters treated as part of words (in addition to letters & numbers)

Why are we setting WORDCHARS to the empty string here?

> bindkey "$key[Home]" beginning-of-line
> bindkey "$key[End]" end-of-line
>
> # Delete: Delete one character to the right or, if that's not possible, list completions.
> # If the list is too long to fit on screen, then start type-ahead search.
> bindkey "$key[Delete]" delete-char-or-list
> zle -C {,.}delete-char-or-list _generic
> zstyle ':completion:delete-char-or-list:*:default' menu yes select=long-list interactive

This is a very unintuitive keybind, I realize that ctrl-d does this,
but I would never expect the delete key to do it. Also see later
comment about menu selection being force enabled.

> # Alt-Delete: Cut the word to the right of the cursor. (opposite of Alt-Backspace)
> bindkey "^[$key[Delete]" kill-word
>
> bindkey '^U' backward-kill-line  # Control-U: Cut text to beginning of line.

ok

> ##
> # Completion settings
> # See http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Standard-Styles
> #
>
> ZLE_REMOVE_SUFFIX_CHARS=$' \t\n;' # Characters that remove completion suffixes.
> ZLE_SPACE_SUFFIX_CHARS=$'&|'      # Characters that instead replace them with a space.
> LISTMAX=0                         # Immediately list completions whenever they fit on screen.
> unsetopt LIST_AMBIGUOUS           # Always list completions when there is more than one match.
> unsetopt LIST_BEEP                # Don't beep when listing completions.
> setopt LIST_PACKED                # Lay out completions as compactly as possible.

ok

> # Initialize the completion system.
> # See http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Use-of-compinit
> # and http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#The-zsh_002fcomplist-Module
> zmodload zsh/complist
> autoload -Uz compinit
> compinit -d ${ZDOTDIR:-$HOME}/.zcompdump
>
> # Enable completion caching & store cache files in a sensible place.
> zstyle ':completion:*' cache-path ${ZDOTDIR:-$HOME}/.zcompcache
> zstyle ':completion:*' use-cache yes
>
> # Tab/Shift-Tab: Start type-ahead completion.
> #   * Tab:        Insert substring shown by `interactive: <prefix>[]<suffix>`.
> #   * Shift-Tab:  Accept selection & start next completion.

Would never expect shift-tab to do anything else than reverse order completion.

> #   * Arrow keys: Change selection.
> #   * Enter:      Accept selection & stop completing.
> zstyle ':completion:(|reverse-)menu-complete:*:default' menu yes select interactive

I don't agree with enabling menu selection by default, but maybe just
because I hate menu selection... It should at any rate be made clearer
how to disable it (in all places).

> bindkey "$key[Tab]" menu-complete
> zle -C {,.}menu-complete _generic
> bindkey "$key[Backtab]" reverse-menu-complete
> zle -C {,.}reverse-menu-complete _generic

I don't think that a "newbie friendly .zshrc" is the place to start
changing the default handler of completion widgets. Also all of these
{,.} everywhere should probably have some explanatory comment, it's
not obvious what those lines are even for (I know, of course, but I
had to think about it... So probably not obvious to a newbie).

> bindkey -M menuselect -s "$key[Backtab]" "$key[Return]$key[Tab]"

How is this different from ^[a (eg, accept-and-hold) in menu selection?

> bindkey -M menuselect "^[$key[Up]"     vi-backward-blank-word # Alt-Up: Previous completion group
> bindkey -M menuselect "^[$key[Down]"   vi-forward-blank-word  # Alt-Down: Next completion group

So we set WORDCHARS to the empty string, then use the vi widgets
anyway for good measure?

> bindkey -M menuselect "$key[PageUp]"   backward-word          # Page Up
> bindkey -M menuselect "$key[PageDown]" forward-word           # Page Down

I think most people expect these keys to scroll history backward/forwards.

> # Try these completers in order until one of them succeeds:
> # _oldlist: try to reuse previous completions
> # _expand: try to substitute expansions (See http://zsh.sourceforge.net/Doc/Release/Expansion.html)
> # _complete: try regular completions
> # _correct: try _complete with spelling correction
> # _complete:-fuzzy: try _complete with a fuzzy matcher
> # _history: try history words
> # _ignored: show completions that have been hidden so far
> zstyle ':completion:*' completer \
>   _oldlist _expand _complete _correct _complete:-fuzzy _history _ignored
>
> # (Shift-)Tab uses old list, if visible.
> zstyle ':completion:(|reverse-)menu-complete:*' old-list shown
> zstyle ':completion:*' old-list never # Other widgets always generate new completions.
>
> # Even when _expand succeeds, if there was only one choice, continue to the next completer.
> zstyle ':completion:*:expand:*' accept-exact continue
>
> zstyle ':completion:*' remove-all-dups yes  # Hide duplicate history words.

ok

> # Each 'string in quotes' is tried in order until one them succeeds.
> # r:|[.]=** does .bar -> foo.bar
> # r:?|[-_]=** does f-b -> foo-bar and F_B -> FOO_BAR
> # l:?|=[-_] does foobar -> foo-bar and FOOBAR -> FOO_BAR
> # m:{[:lower:]-}={[:upper:]_} does foo-bar -> FOO_BAR (but not vice versa)
> # r:|?=** does fbr -> foo-bar and bar -> foo-bar
> zstyle ':completion:*:complete:*' matcher-list \
>   'r:|[.]=** r:?|[-_]=** l:?|=[-_] m:{[:lower:]-}={[:upper:]_}'
> zstyle ':completion:*:complete-fuzzy:*' matcher-list \
>   'r:|?=** m:{[:lower:]}={[:upper:]}'
> zstyle ':completion:*:options' matcher 'b:-=+'  # For options, do -x -> +x

possibly a bit magic but ok.

> # Hide certain completions, unless we get no other completions.
> zstyle ':completion:*' prefix-needed yes            # Params & functions starting with `.` or `_`
> zstyle ':completion:*:users' ignored-patterns '_*'  # Users starting with `_`
>
> zstyle ':completion:*' group-name ''                # Organize completions in groups.
> zstyle ':completion:*:descriptions' format '%B%d%b' # Show group titles in bold.
> zstyle ':completion:*:expansions' format "%B%d%b for '%o'"
> zstyle ':completion:*:corrections' format '%B%d%b for %F{red}%o%f (%e typo(s))'
> zstyle ':completion:*' list-dirs-first yes          # Group dirs separately from other files.
> zstyle ':completion:*' separate-sections yes        # Show `man` and `dict` sections.
> zstyle ':completion:*' insert-sections yes          # Insert `man` sections.
> zstyle ':completion:*:default' list-prompt ''       # Enable completion list scrolling.
>
> # Add color to messages and warnings.
> zstyle ':completion:*:messages' format "%F{r}%d%f"
> zstyle ':completion:*:warnings' format '%F{r}No %d found.%f'
>
> # Initialize `$color` table.
> autoload -Uz colors
> colors
> unfunction colors

it's too bad show-ambiguity needs this because otherwise colors is
largely depracated by "new" prompt codes so this part is a bit
confusing perhaps.

> # Highlight next differentiating character.
> zstyle ':completion:*:default' show-ambiguity "$color[black];$color[bg-yellow]"

I disagree with using this, it disables colored filetypes doesn't it?

> zstyle ':completion:*' list-separator ''  # Eliminate some false positives.
> # Reuse $LS_COLORS for completion highlighting and add additional colors.
> # See http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#Colored-completion-listings
> # zstyle -e: Evaluate the given code each time this style gets checked.
> # See end of section http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Overview-1
> zstyle -e ':completion:*:default' list-colors .zshrc.list-colors
> .zshrc.list-colors() {
>   reply=(
>     ${(s.:.)LS_COLORS}
>     "ma=$color[bold];$color[white];$color[bg-blue]" # Menu selection
>     "sa=$color[green];$color[underline]"            # Suffix aliases
>     "(global-aliases|parameters)=*=$color[cyan]"
>     "(aliases|executables|functions|commands|builtins|jobs)=*=$color[green]"
>     "(reserved-words)=*=$color[yellow];$color[bg-black]"
>     "(glob(flags|quals)|modifiers)=*=$color[blue]"
>   )
> }

ok

> ##
> # Directory settings
> # See http://zsh.sourceforge.net/Doc/Release/Options.html#Changing-Directories
> #
>
> setopt AUTO_CD            # Change dirs simply by typing a dir name. No `cd` required.
> setopt AUTO_PUSHD         # Auto-store each dir we visit in the dir stack.
> setopt PUSHD_SILENT       # Don't print the dir stack when using `pushd`.
> setopt PUSHD_IGNORE_DUPS  # Discard duplicate entries.
>
> bindkey -s '^[-' "^Qpushd -1$key[Return]"   # Alt-Minus:  Back to previous dir stack entry.
> bindkey -s '^[=' "^Qpushd +0$key[Return]"   # Alt-Equals: Forward to next dir stack entry.

Might go as far as say NAK on these bindkey -s abominations.

> setopt PUSHD_MINUS                          # `~-` + Tab: Select a dir stack entry.
> bindkey -s "^[$key[Up]" "^Q..$key[Return]"  # Alt-Up:     Up to parent dir.
> bindkey "^[$key[Down]" menu-select          # Alt-Down:   Select a local dir or file.
> zle -C {,}menu-select _generic

More random default completion widgets changing even though we are
long done with completion settings...

> zstyle ':completion:menu-select:*:default'  menu yes select interactive

Another place to find for a poor user who wants to disable menu selection...

> zstyle ':completion:menu-select:*:-command-:*' tag-order \
>   'globbed-files executables (|local-)directories suffix-aliases' -
> zstyle ':completion:menu-select:*' tag-order '(|*-)directories (|*-)files' -

these two need comments

> # Auto-save last 20 dirs to file whenever we change dirs.
> # See http://zsh.sourceforge.net/Doc/Release/User-Contributions.html#Recent-Directories
> autoload -Uz add-zsh-hook chpwd_recent_dirs
> add-zsh-hook chpwd chpwd_recent_dirs
> zstyle ':chpwd:*' recent-dirs-file ${ZDOTDIR:-$HOME}/.chpwd-recent-dirs
>
> # On startup, initialize dir stack from file.
> autoload -Uz chpwd_recent_filehandler
> chpwd_recent_filehandler
> cd $reply[1]
> dirs $reply[@] >/dev/null

Does this start zsh in some other directory than it inherited from the
terminal? If so, nak from me on that, way too surprising.

> ##
> # Miscellaneous shell options
> # See http://zsh.sourceforge.net/Doc/Release/Options.html
> #
>
> setopt GLOB_STAR_SHORT    # Use `**` for recursive globbing; `***` to also traverse symlinks.

** and *** already exist without this option, confusingly phrased.

> setopt NUMERIC_GLOB_SORT  # Sort numeric matches numerically, not lexicographically.
> setopt EXTENDED_GLOB      # Enable additional pattern matching operators.
> # See http://zsh.sourceforge.net/Doc/Release/Expansion.html#Filename-Generation
>
> unsetopt CLOBBER            # Don't let `>` overwrite files. Use `>|` instead.
> setopt INTERACTIVE_COMMENTS # Allow comments on the command line.

ok

> ##
> # Other settings
> #
>
> # Make each entry in these Unique (that is, remove duplicates).
> # See http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html#index-typeset
> typeset -gU PATH path FPATH fpath CDPATH cdpath MANPATH manpath

specifying the scalar halves of these tied variables is superfluous.

> # Add some basic command line highlighting.
> # See http://zsh.sourceforge.net/Doc/Release/Zsh-Line-Editor.html#Character-Highlighting
> zle_highlight=(
>   isearch:fg=black,bg=yellow  # Matched search text
>   paste:none                  # Yanked/pasted text
>   region:bg=blue              # Selected text
>   special:fg=cyan,bold        # Unprintable characters
>   suffix:bg=blue              # Auto-removable suffix inserted by completion
> )

There are many colors, why use the same for the region and the suffix?

> # Use suffix aliases to associate file extensions with commands.
> # This way, you can open a file simply by typing its name.
> # See http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html#index-alias
> READNULLCMD='less'      # Makes `< foo` do `less < foo`.
> alias -s txt='<' md='<' # .txt and .md files
> alias -s log='tail -f'  # .log files

Letting the user type < for less is one thing, but you don't really
save anything by using a shorter command in the rhs of an alias... it
does doesn't allow the user to type more than one filename. eg:
% < file1 file2
zsh: command not found: file2
% less file1 file2
file1 (file 1 of 2) lines ?-?/? (END) - Next: file2


Overall I think there's a bit too much stuff in here. It's longer than
some (many) actual personal .zshrc files I've seen.

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-05 19:44 Rewrite of zsh-newuser-install (Mikael's subthread) Mikael Magnusson
@ 2021-04-05 21:01 ` Mikael Magnusson
  2021-04-05 21:44 ` Bart Schaefer
  2021-04-07 14:28 ` Marlon
  2 siblings, 0 replies; 28+ messages in thread
From: Mikael Magnusson @ 2021-04-05 21:01 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On 4/5/21, Mikael Magnusson <mikachu@gmail.com> wrote:
>> bindkey "$key[Backtab]" reverse-menu-complete
>> bindkey -M menuselect -s "$key[Backtab]" "$key[Return]$key[Tab]"

Also just noticed you have both of these, so if you press shift-tab
twice it will first do a reverse-menu-complete inserting the last
match, then if you press it again it accepts it and inserts the first
match.

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-05 19:44 Rewrite of zsh-newuser-install (Mikael's subthread) Mikael Magnusson
  2021-04-05 21:01 ` Mikael Magnusson
@ 2021-04-05 21:44 ` Bart Schaefer
  2021-04-07 13:44   ` Marlon
  2021-04-07 14:28 ` Marlon
  2 siblings, 1 reply; 28+ messages in thread
From: Bart Schaefer @ 2021-04-05 21:44 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Marlon Richert, Zsh hackers list

On Mon, Apr 5, 2021 at 12:44 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> > # Prompt settings
>
> This is 70 lines that should be a prompt theme, not pasted verbatim in .zshrc.

There was some side discussion about prompt themes being unmaintained
and therefore unsuitable for this.  My take is that we should find a
way to put some effort into maintaining it.  We did just have a few
patches for it, so I personally would be fine with this going into a
theme.

> > typeset -A key  # Declare `$key` table, without overriding any existing values.
>
> How could $key possibly already exist as an associative array at this
> point?

Also, won't this by default print everything that's already in $key if
by some magic (/etc/zsh* or ~/.zshenv ?) it does already exist?

> > WORDCHARS=''  # Characters treated as part of words (in addition to letters & numbers)
>
> Why are we setting WORDCHARS to the empty string here?

There was a side discussion about this, too.  The default WORDCHARS
acts like the stty driver, emptying it works more like emacs.

> > bindkey -M menuselect "$key[PageUp]"   backward-word          # Page Up
> > bindkey -M menuselect "$key[PageDown]" forward-word           # Page Down
>
> I think most people expect these keys to scroll history backward/forwards.

I don't recall what difference being in the menuselect keymap makes here.

> > bindkey -s '^[-' "^Qpushd -1$key[Return]"   # Alt-Minus:  Back to previous dir stack entry.
> > bindkey -s '^[=' "^Qpushd +0$key[Return]"   # Alt-Equals: Forward to next dir stack entry.
>
> Might go as far as say NAK on these bindkey -s abominations.

Yeurgh.  Agree, avoid bindkey -s.

> > # Make each entry in these Unique (that is, remove duplicates).
> > # See http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html#index-typeset
> > typeset -gU PATH path FPATH fpath CDPATH cdpath MANPATH manpath
>
> specifying the scalar halves of these tied variables is superfluous.

Again, previously discussed ... the man page recommends specifying
both halves because of the -U option.

> Overall I think there's a bit too much stuff in here. It's longer than
> some (many) actual personal .zshrc files I've seen.

I tend to agree.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-05 21:44 ` Bart Schaefer
@ 2021-04-07 13:44   ` Marlon
  2021-04-07 16:24     ` Daniel Shahaf
  0 siblings, 1 reply; 28+ messages in thread
From: Marlon @ 2021-04-07 13:44 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Mikael Magnusson, Zsh hackers list

On 6. Apr 2021, at 0.44, Bart Schaefer <schaefer@brasslantern.com> wrote:
> 
> On Mon, Apr 5, 2021 at 12:44 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>> 
>>> # Prompt settings
>> 
>> This is 70 lines that should be a prompt theme, not pasted verbatim in .zshrc.
> 
> There was some side discussion about prompt themes being unmaintained
> and therefore unsuitable for this.  My take is that we should find a
> way to put some effort into maintaining it.  We did just have a few
> patches for it, so I personally would be fine with this going into a
> theme.

Sure, I can make a theme out of it. I think it’s important, though, to then make said theme sufficiently easy for the end user to customize. As Roman pointed out way in the beginning of the thread, one of the top things that user want to customize in their shell is their prompt. I will try to make it as easy possible for them.


> 
>>> typeset -A key  # Declare `$key` table, without overriding any existing values.
>> 
>> How could $key possibly already exist as an associative array at this
>> point?

It is created in /etc/zshrc on both macOS and Debian.

> Also, won't this by default print everything that's already in $key if
> by some magic (/etc/zsh* or ~/.zshenv ?) it does already exist?

I tested it and it doesn’t.


>>> bindkey -M menuselect "$key[PageUp]"   backward-word          # Page Up
>>> bindkey -M menuselect "$key[PageDown]" forward-word           # Page Down
>> 
>> I think most people expect these keys to scroll history backward/forwards.
> 
> I don't recall what difference being in the menuselect keymap makes here.

These apply to complist's menu selection only. Being able to page up/down in long completion menus is very handy.


>>> bindkey -s '^[-' "^Qpushd -1$key[Return]"   # Alt-Minus:  Back to previous dir stack entry.
>>> bindkey -s '^[=' "^Qpushd +0$key[Return]"   # Alt-Equals: Forward to next dir stack entry.
>> 
>> Might go as far as say NAK on these bindkey -s abominations.
> 
> Yeurgh.  Agree, avoid bindkey -s.

Sure, I could make these into autoloadable functions instead.


>> Overall I think there's a bit too much stuff in here. It's longer than
>> some (many) actual personal .zshrc files I've seen.
> 
> I tend to agree.

The feedback I’ve gotten, however, from the Zsh packagers for ALT Linux, Adélie Linux, openSuse and Fedora is that it’s good stuff. :)

Some quotes:

"this zshrc offers a lot of tricks I personally wanted to use but didn't know they were already implemented; thanks a lot for shining a light on them!”

"I gave it a spin and it looks very nice, much less scary than the default one. I've checked the default .zshrc and it looks fine to me."



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-05 19:44 Rewrite of zsh-newuser-install (Mikael's subthread) Mikael Magnusson
  2021-04-05 21:01 ` Mikael Magnusson
  2021-04-05 21:44 ` Bart Schaefer
@ 2021-04-07 14:28 ` Marlon
  2021-04-07 15:14   ` Daniel Shahaf
                     ` (3 more replies)
  2 siblings, 4 replies; 28+ messages in thread
From: Marlon @ 2021-04-07 14:28 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Zsh hackers list


> On 5. Apr 2021, at 22.44, Mikael Magnusson <mikachu@gmail.com> wrote:
> 
> On 4/5/21, Marlon Richert <marlon.richert@gmail.com> wrote:
>> #
>> # Type `zrestart` to safely apply changes after editing this file.
>> #
>> zrestart() {
>>  local zshrc=${ZDOTDIR:-$HOME}/.zshrc
>>  print -P "Validating %U$zshrc%u..."
>>  zsh -nf $zshrc ||
>>    return
>> 
>>  print -P 'Restarting Zsh...'
>>  zsh -l &&
>>    exit
>> }
> 
> This could be an autoloadable function, not pasted verbatim in .zshrc.
> Also disagree with -l here. You can use $options[login] or $- to see
> if you're in a login shell already and start same. Things like this we
> can't fix after users already copy this config. It should try to
> mostly be configuration, not helper functions that can have permanent
> flaws once installed.

Sure, I can move it to an autoloadable function. That’s fine by me. I did not come up with the -l, though. Earlier in the thread, Oliver & Bart didn’t like using `exec zsh` and offered this instead. See [48031](https://www.zsh.org/mla/workers/2021/msg00244.html). I’d be happy to change it, but I don’t know how they feel about it.


>> setopt EXTENDED_HISTORY         # Save each command's time & duration to history.
>> setopt INC_APPEND_HISTORY_TIME  # Save history whenever a command finishes, not just on shell exit.
>> setopt HIST_EXPIRE_DUPS_FIRST   # Delete duplicate history lines first, when running out of space.
>> setopt HIST_IGNORE_DUPS         # Don't store last command line if identical to previous one.
> 
> ok, I don't agree with the dups settings but they're changeable easily.

Personally, I would’ve preferred `setopt HIST_IGNORE_ALL_DUPS SHARE_HISTORY`, but there were several votes against that earlier in this thread.


>> # Up/Down: Cycle through history lines that start with same word as command line.
>> zle -A up-line-or-{search,history}
>> zle -A down-line-or-{search,history}
> 
> These two lines don't actually bind any keys, but the comment claims they do.

They change the default widgets bound to up/down, which makes for more elegant code, since we don’t have to deal with app vs raw mode.


>> # Delete: Delete one character to the right or, if that's not possible, list completions.
>> # If the list is too long to fit on screen, then start type-ahead search.
>> bindkey "$key[Delete]" delete-char-or-list
>> zle -C {,.}delete-char-or-list _generic
>> zstyle ':completion:delete-char-or-list:*:default' menu yes select=long-list interactive
> 
> This is a very unintuitive keybind, I realize that ctrl-d does this,
> but I would never expect the delete key to do it. Also see later
> comment about menu selection being force enabled.

Sure, I can make it do just delete.


>> # Tab/Shift-Tab: Start type-ahead completion.
>> #   * Tab:        Insert substring shown by `interactive: <prefix>[]<suffix>`.
>> #   * Shift-Tab:  Accept selection & start next completion.
> 
> Would never expect shift-tab to do anything else than reverse order completion.

I would expect Tab to insert the current selection, not insert an “unambiguous” prefix or _just do nothing_ when such a prefix doesn’t exist. However, I don’t want to override the defaults when I can avoid it. So, that’s why I added Backtab to do what, since that actually doesn’t have any function by default; not in the ZLE and not in complist’s `interactive` mode.

Also, in complist’s `interactive` mode, Tab does _not_ cycle forward, but inserts “unambiguous". Ergo, in this context, I would _not_ expect to Backtab to cycle backwards.


>> #   * Arrow keys: Change selection.
>> #   * Enter:      Accept selection & stop completing.
>> zstyle ':completion:(|reverse-)menu-complete:*:default' menu yes select interactive
> 
> I don't agree with enabling menu selection by default, but maybe just
> because I hate menu selection... It should at any rate be made clearer
> how to disable it (in all places).

`interactive` means it’s not actual menu selection, though. Instead, it enables type-ahead completion, which is an extremely useful complist feature.


>> bindkey "$key[Tab]" menu-complete
>> zle -C {,.}menu-complete _generic
>> bindkey "$key[Backtab]" reverse-menu-complete
>> zle -C {,.}reverse-menu-complete _generic
> 
> I don't think that a "newbie friendly .zshrc" is the place to start
> changing the default handler of completion widgets. Also all of these
> {,.} everywhere should probably have some explanatory comment, it's
> not obvious what those lines are even for (I know, of course, but I
> had to think about it... So probably not obvious to a newbie).

Sadly, without using _generic, it’s not possible to enable or disable menu selection on an individual widget basis. That’s why I filed [48194](https://www.zsh.org/mla/workers/2021/msg00407.html). I, too, would prefer this code not to go into the .zshrc file.


> 
>> bindkey -M menuselect -s "$key[Backtab]" "$key[Return]$key[Tab]"
> 
> How is this different from ^[a (eg, accept-and-hold) in menu selection?

accept-and-hold doesn’t work correctly with, for example, directory completions. To see this for yourself, try `cd /` + Tab + ^[a. Then try `cd /` + Tab + Backtab. Notice the difference. The first one makes no sense.


>> bindkey -M menuselect "^[$key[Up]"     vi-backward-blank-word # Alt-Up: Previous completion group
>> bindkey -M menuselect "^[$key[Down]"   vi-forward-blank-word  # Alt-Down: Next completion group
> 
> So we set WORDCHARS to the empty string, then use the vi widgets
> anyway for good measure?

These are complist features. It does what it says in the comments: vi-backward-blank-word moves to the previous completion group in the completion menu; vi-forward-blank-word moves to the next  completion group in the completion menu.


>> # Highlight next differentiating character.
>> zstyle ':completion:*:default' show-ambiguity "$color[black];$color[bg-yellow]"
> 
> I disagree with using this, it disables colored filetypes doesn't it?

Only when there is an “unambiguous” prefix that can be inserted. But I guess since we use `interactive` complist, this isn’t really necessary. I will remove it.


>> setopt PUSHD_MINUS                          # `~-` + Tab: Select a dir stack entry.
>> bindkey -s "^[$key[Up]" "^Q..$key[Return]"  # Alt-Up:     Up to parent dir.
>> bindkey "^[$key[Down]" menu-select          # Alt-Down:   Select a local dir or file.
>> zle -C {,}menu-select _generic
> 
> More random default completion widgets changing even though we are
> long done with completion settings...

No, I’m just creating two handy, generic widgets here. Using the completion system for it is just an implementation detail. But I can move those, too, into an autoloadable function; no problem.


>> zstyle ':completion:menu-select:*:-command-:*' tag-order \
>>  'globbed-files executables (|local-)directories suffix-aliases' -
>> zstyle ':completion:menu-select:*' tag-order '(|*-)directories (|*-)files' -
> 
> these two need comments

Sure, I’ll add.


>> # Auto-save last 20 dirs to file whenever we change dirs.
>> # See http://zsh.sourceforge.net/Doc/Release/User-Contributions.html#Recent-Directories
>> autoload -Uz add-zsh-hook chpwd_recent_dirs
>> add-zsh-hook chpwd chpwd_recent_dirs
>> zstyle ':chpwd:*' recent-dirs-file ${ZDOTDIR:-$HOME}/.chpwd-recent-dirs
>> 
>> # On startup, initialize dir stack from file.
>> autoload -Uz chpwd_recent_filehandler
>> chpwd_recent_filehandler
>> cd $reply[1]
>> dirs $reply[@] >/dev/null
> 
> Does this start zsh in some other directory than it inherited from the
> terminal? If so, nak from me on that, way too surprising.

It makes the shell pick up in the same dir as where you left off last time. I would hardly call that surprising. In fact, I would pretty much call that _expected_ for most applications nowadays.


>> ##
>> # Miscellaneous shell options
>> # See http://zsh.sourceforge.net/Doc/Release/Options.html
>> #
>> 
>> setopt GLOB_STAR_SHORT    # Use `**` for recursive globbing; `***` to also traverse symlinks.
> 
> ** and *** already exist without this option, confusingly phrased.

Sure, I can make that comment longer. There was already a remark about that earlier. I just prefer to keep everything as concise as possible. Usability research teaches us that the more text there is, the less likely anyone will read it.


>> # Add some basic command line highlighting.
>> # See http://zsh.sourceforge.net/Doc/Release/Zsh-Line-Editor.html#Character-Highlighting
>> zle_highlight=(
>>  isearch:fg=black,bg=yellow  # Matched search text
>>  paste:none                  # Yanked/pasted text
>>  region:bg=blue              # Selected text
>>  special:fg=cyan,bold        # Unprintable characters
>>  suffix:bg=blue              # Auto-removable suffix inserted by completion
>> )
> 
> There are many colors, why use the same for the region and the suffix?

Because it’s familiar from the GUI world: If text looks selected, then you expect it to be replaced when you type over it.


>> # Use suffix aliases to associate file extensions with commands.
>> # This way, you can open a file simply by typing its name.
>> # See http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html#index-alias
>> READNULLCMD='less'      # Makes `< foo` do `less < foo`.
>> alias -s txt='<' md='<' # .txt and .md files
>> alias -s log='tail -f'  # .log files
> 
> Letting the user type < for less is one thing, but you don't really
> save anything by using a shorter command in the rhs of an alias... it
> does doesn't allow the user to type more than one filename. eg:
> % < file1 file2
> zsh: command not found: file2
> % less file1 file2
> file1 (file 1 of 2) lines ?-?/? (END) - Next: file2

There’s no harm in it, though, is there? Plus it makes it so you Don’t Repeat Yourself. Now you have only variable you need to change when you want to move from `less` to, say, `bat`.


On 6. Apr 2021, at 0.01, Mikael Magnusson <mikachu@gmail.com> wrote:
> 
> On 4/5/21, Mikael Magnusson <mikachu@gmail.com> wrote:
>>> bindkey "$key[Backtab]" reverse-menu-complete
>>> bindkey -M menuselect -s "$key[Backtab]" "$key[Return]$key[Tab]"
> 
> Also just noticed you have both of these, so if you press shift-tab
> twice it will first do a reverse-menu-complete inserting the last
> match, then if you press it again it accepts it and inserts the first
> match.

Yeah, perhaps those two don’t really make sense together. I would like there to be a completion menu shortcut that inserts the current selection and then immediately completes again, but that doesn’t really rhyme with reverse-menu-complete.



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-07 14:28 ` Marlon
@ 2021-04-07 15:14   ` Daniel Shahaf
  2021-04-07 16:36   ` Bart Schaefer
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 28+ messages in thread
From: Daniel Shahaf @ 2021-04-07 15:14 UTC (permalink / raw)
  To: Marlon; +Cc: Mikael Magnusson, Zsh hackers list

Marlon wrote on Wed, Apr 07, 2021 at 17:28:29 +0300:
> On 5. Apr 2021, at 22.44, Mikael Magnusson <mikachu@gmail.com> wrote:
> > On 4/5/21, Marlon Richert <marlon.richert@gmail.com> wrote:
> >> # Use suffix aliases to associate file extensions with commands.
> >> # This way, you can open a file simply by typing its name.
> >> # See http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html#index-alias
> >> READNULLCMD='less'      # Makes `< foo` do `less < foo`.
> >> alias -s txt='<' md='<' # .txt and .md files
> >> alias -s log='tail -f'  # .log files
> > 
> > Letting the user type < for less is one thing, but you don't really
> > save anything by using a shorter command in the rhs of an alias... it
> > does doesn't allow the user to type more than one filename. eg:
> > % < file1 file2
> > zsh: command not found: file2
> > % less file1 file2
> > file1 (file 1 of 2) lines ?-?/? (END) - Next: file2
> 
> There’s no harm in it, though, is there?

Use of identifiers that consist of punctuation only makes the code more
difficult to read / understand / look up.  For instance, given the
documentation of «alias -s», a new user might look up a «<» command in
the index.

> Plus it makes it so you Don’t Repeat Yourself. Now you have only
> variable you need to change when you want to move from `less` to, say,
> `bat`.

There's a clearer way to do that:

    alias -s txt='$READNULLCMD'

or, to mimic the built-in semantics of $READNULLCMD falling back to $NULLCMD:

    alias -s txt='${READNULLCMD:-${NULLCMD}}'



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-07 13:44   ` Marlon
@ 2021-04-07 16:24     ` Daniel Shahaf
  2021-04-10 11:23       ` Marlon
  0 siblings, 1 reply; 28+ messages in thread
From: Daniel Shahaf @ 2021-04-07 16:24 UTC (permalink / raw)
  To: Marlon; +Cc: Zsh hackers list

Marlon wrote on Wed, Apr 07, 2021 at 16:44:54 +0300:
> On 6. Apr 2021, at 0.44, Bart Schaefer <schaefer@brasslantern.com> wrote:
> > On Mon, Apr 5, 2021 at 12:44 PM Mikael Magnusson <mikachu@gmail.com> wrote:
> >> Overall I think there's a bit too much stuff in here. It's longer than
> >> some (many) actual personal .zshrc files I've seen.
> > 
> > I tend to agree.
> 
> The feedback I’ve gotten, however, from the Zsh packagers for ALT Linux, Adélie Linux, openSuse and Fedora is that it’s good stuff. :)

I think there's a distinction to be drawn between "stuff we should
enable in the default zshrc" and "cool stuff that people might want to
use, or read to learn about useful tricks/features".

I agree with Mikael and Bart that most of your zshrc falls under the
latter category.  That has its place (cf. Misc/vcs_info-examples), but
it's too magical for the default.

That's also one of the standard criticisms against oh-my-zsh, by the way.

> Some quotes:
> 
> "this zshrc offers a lot of tricks I personally wanted to use but didn't know they were already implemented; thanks a lot for shining a light on them!”
> 
> "I gave it a spin and it looks very nice, much less scary than the default one. I've checked the default .zshrc and it looks fine to me."

If the author of the second quote wishes to join this thread, they're of
course welcome to do so.  They might change their opinion, or change
ours.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-07 14:28 ` Marlon
  2021-04-07 15:14   ` Daniel Shahaf
@ 2021-04-07 16:36   ` Bart Schaefer
  2021-04-07 18:15   ` Mikael Magnusson
  2021-04-09 15:29   ` Marlon
  3 siblings, 0 replies; 28+ messages in thread
From: Bart Schaefer @ 2021-04-07 16:36 UTC (permalink / raw)
  To: Marlon; +Cc: Mikael Magnusson, Zsh hackers list

On Wed, Apr 7, 2021 at 7:29 AM Marlon <marlon.richert@gmail.com> wrote:
>
> [...] that’s why I added Backtab to do what, since that actually doesn’t have any function by default [...]

It doesn't have a function because (formerly, at least) a lot of
keyboards didn't recognize Shift-Tab as different from Tab.

> Sadly, without using _generic, it’s not possible to enable or disable menu selection on an individual widget basis.

zstyle -e ':completion::*:default' menu \
  '[[ $WIDGET = (|reverse-)menu-complete ]] && reply=(yes select interactive)'

> >> # On startup, initialize dir stack from file.
> >
> > Does this start zsh in some other directory than it inherited from the
> > terminal? If so, nak from me on that, way too surprising.
>
> It makes the shell pick up in the same dir as where you left off last time. I would hardly call that surprising. In fact, I would pretty much call that _expected_ for most applications nowadays.

That would drive me insane unless the directory were somehow bound to
the window position (which we've already debated and concluded is
impossible in all but some very specific circumstances).  I definitely
DO NOT want every new shell starting in whatever directory I last had
a shell in, particularly for remote shells.   A shell is not like
"most applications".


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-07 14:28 ` Marlon
  2021-04-07 15:14   ` Daniel Shahaf
  2021-04-07 16:36   ` Bart Schaefer
@ 2021-04-07 18:15   ` Mikael Magnusson
  2021-04-07 18:50     ` Daniel Shahaf
                       ` (2 more replies)
  2021-04-09 15:29   ` Marlon
  3 siblings, 3 replies; 28+ messages in thread
From: Mikael Magnusson @ 2021-04-07 18:15 UTC (permalink / raw)
  To: Marlon; +Cc: Zsh hackers list

On 4/7/21, Marlon <marlon.richert@gmail.com> wrote:
>
>> On 5. Apr 2021, at 22.44, Mikael Magnusson <mikachu@gmail.com> wrote:
>>
>> On 4/5/21, Marlon Richert <marlon.richert@gmail.com> wrote:
>>> #
>>> # Type `zrestart` to safely apply changes after editing this file.
>>> #
>>> zrestart() {
>>>  local zshrc=${ZDOTDIR:-$HOME}/.zshrc
>>>  print -P "Validating %U$zshrc%u..."
>>>  zsh -nf $zshrc ||
>>>    return
>>>
>>>  print -P 'Restarting Zsh...'
>>>  zsh -l &&
>>>    exit
>>> }
>>
>> This could be an autoloadable function, not pasted verbatim in .zshrc.
>> Also disagree with -l here. You can use $options[login] or $- to see
>> if you're in a login shell already and start same. Things like this we
>> can't fix after users already copy this config. It should try to
>> mostly be configuration, not helper functions that can have permanent
>> flaws once installed.
>
> Sure, I can move it to an autoloadable function. That’s fine by me. I did
> not come up with the -l, though. Earlier in the thread, Oliver & Bart didn’t
> like using `exec zsh` and offered this instead. See
> [48031](https://www.zsh.org/mla/workers/2021/msg00244.html). I’d be happy to
> change it, but I don’t know how they feel about it.

You could also just have a comment saying something to the effect of
"changes to this file will only take effect in new shells, you can
either open a new terminal or type "zsh" in an existing terminal". I
guess I don't care too much either way after all.

>>> setopt EXTENDED_HISTORY         # Save each command's time & duration to
>>> history.
>>> setopt INC_APPEND_HISTORY_TIME  # Save history whenever a command
>>> finishes, not just on shell exit.
>>> setopt HIST_EXPIRE_DUPS_FIRST   # Delete duplicate history lines first,
>>> when running out of space.
>>> setopt HIST_IGNORE_DUPS         # Don't store last command line if
>>> identical to previous one.
>>
>> ok, I don't agree with the dups settings but they're changeable easily.
>
> Personally, I would’ve preferred `setopt HIST_IGNORE_ALL_DUPS
> SHARE_HISTORY`, but there were several votes against that earlier in this
> thread.

I'm glad, those are even worse :).

>>> # Up/Down: Cycle through history lines that start with same word as
>>> command line.
>>> zle -A up-line-or-{search,history}
>>> zle -A down-line-or-{search,history}
>>
>> These two lines don't actually bind any keys, but the comment claims they
>> do.
>
> They change the default widgets bound to up/down, which makes for more
> elegant code, since we don’t have to deal with app vs raw mode.

Ah, I didn't realize that's what you did because the {,} stuff makes
it way too hard to understand at a glance. What you're doing is in
fact making it impossible (unless the new user knows about .widgets)
for the user to bind up-line-or-search to any other key, without first
hunting down and deleting these two lines. I don't like it... Overall
I would say you should get rid of all brace expansions.

[snipped delete]

>>> # Tab/Shift-Tab: Start type-ahead completion.
>>> #   * Tab:        Insert substring shown by `interactive:
>>> <prefix>[]<suffix>`.
>>> #   * Shift-Tab:  Accept selection & start next completion.
>>
>> Would never expect shift-tab to do anything else than reverse order
>> completion.
>
> I would expect Tab to insert the current selection, not insert an
> “unambiguous” prefix or _just do nothing_ when such a prefix doesn’t exist.
> However, I don’t want to override the defaults when I can avoid it. So,
> that’s why I added Backtab to do what, since that actually doesn’t have any
> function by default; not in the ZLE and not in complist’s `interactive`
> mode.
>
> Also, in complist’s `interactive` mode, Tab does _not_ cycle forward, but
> inserts “unambiguous". Ergo, in this context, I would _not_ expect to
> Backtab to cycle backwards.

tab will insert the unambiguous part, and then start cycling
(depending on your setopts, this takes anywhere from 0 to 4 or so tab
presses).

>>> #   * Arrow keys: Change selection.
>>> #   * Enter:      Accept selection & stop completing.
>>> zstyle ':completion:(|reverse-)menu-complete:*:default' menu yes select
>>> interactive
>>
>> I don't agree with enabling menu selection by default, but maybe just
>> because I hate menu selection... It should at any rate be made clearer
>> how to disable it (in all places).
>
> `interactive` means it’s not actual menu selection, though. Instead, it
> enables type-ahead completion, which is an extremely useful complist
> feature.

Well, I'd have the same objection to either of them, that it's quite a
huge departure from the standard mode of operation which is typing
normally and pressing tab to complete words.

>>> bindkey "$key[Tab]" menu-complete
>>> zle -C {,.}menu-complete _generic
>>> bindkey "$key[Backtab]" reverse-menu-complete
>>> zle -C {,.}reverse-menu-complete _generic
>>
>> I don't think that a "newbie friendly .zshrc" is the place to start
>> changing the default handler of completion widgets. Also all of these
>> {,.} everywhere should probably have some explanatory comment, it's
>> not obvious what those lines are even for (I know, of course, but I
>> had to think about it... So probably not obvious to a newbie).
>
> Sadly, without using _generic, it’s not possible to enable or disable menu
> selection on an individual widget basis. That’s why I filed
> [48194](https://www.zsh.org/mla/workers/2021/msg00407.html). I, too, would
> prefer this code not to go into the .zshrc file.

Would also be resolved by not enabling menu selection :).

>>> bindkey -M menuselect -s "$key[Backtab]" "$key[Return]$key[Tab]"
>>
>> How is this different from ^[a (eg, accept-and-hold) in menu selection?
>
> accept-and-hold doesn’t work correctly with, for example, directory
> completions. To see this for yourself, try `cd /` + Tab + ^[a. Then try `cd
> /` + Tab + Backtab. Notice the difference. The first one makes no sense.

In that particular use case I think you would use accept-and-infer-next-history.

>>> bindkey -M menuselect "^[$key[Up]"     vi-backward-blank-word # Alt-Up:
>>> Previous completion group
>>> bindkey -M menuselect "^[$key[Down]"   vi-forward-blank-word  # Alt-Down:
>>> Next completion group
>>
>> So we set WORDCHARS to the empty string, then use the vi widgets
>> anyway for good measure?
>
> These are complist features. It does what it says in the comments:
> vi-backward-blank-word moves to the previous completion group in the
> completion menu; vi-forward-blank-word moves to the next  completion group
> in the completion menu.

I didn't notice the -M menuselect parts of these, which means a new
user probably won't either, should be commented that these apply only
to menu selection mode, and possibly all of these should be grouped
together if they stay.

[snipped some stuff]

>>> # Auto-save last 20 dirs to file whenever we change dirs.
>>> # See
>>> http://zsh.sourceforge.net/Doc/Release/User-Contributions.html#Recent-Directories
>>> autoload -Uz add-zsh-hook chpwd_recent_dirs
>>> add-zsh-hook chpwd chpwd_recent_dirs
>>> zstyle ':chpwd:*' recent-dirs-file ${ZDOTDIR:-$HOME}/.chpwd-recent-dirs
>>>
>>> # On startup, initialize dir stack from file.
>>> autoload -Uz chpwd_recent_filehandler
>>> chpwd_recent_filehandler
>>> cd $reply[1]
>>> dirs $reply[@] >/dev/null
>>
>> Does this start zsh in some other directory than it inherited from the
>> terminal? If so, nak from me on that, way too surprising.
>
> It makes the shell pick up in the same dir as where you left off last time.
> I would hardly call that surprising. In fact, I would pretty much call that
> _expected_ for most applications nowadays.

I think most people on the list will strongly disagree with you here.

>>> ##
>>> # Miscellaneous shell options
>>> # See http://zsh.sourceforge.net/Doc/Release/Options.html
>>> #
>>>
>>> setopt GLOB_STAR_SHORT    # Use `**` for recursive globbing; `***` to
>>> also traverse symlinks.
>>
>> ** and *** already exist without this option, confusingly phrased.
>
> Sure, I can make that comment longer. There was already a remark about that
> earlier. I just prefer to keep everything as concise as possible. Usability
> research teaches us that the more text there is, the less likely anyone will
> read it.
>
>
>>> # Add some basic command line highlighting.
>>> # See
>>> http://zsh.sourceforge.net/Doc/Release/Zsh-Line-Editor.html#Character-Highlighting
>>> zle_highlight=(
>>>  isearch:fg=black,bg=yellow  # Matched search text
>>>  paste:none                  # Yanked/pasted text
>>>  region:bg=blue              # Selected text
>>>  special:fg=cyan,bold        # Unprintable characters
>>>  suffix:bg=blue              # Auto-removable suffix inserted by
>>> completion
>>> )
>>
>> There are many colors, why use the same for the region and the suffix?
>
> Because it’s familiar from the GUI world: If text looks selected, then you
> expect it to be replaced when you type over it.
>
>
>>> # Use suffix aliases to associate file extensions with commands.
>>> # This way, you can open a file simply by typing its name.
>>> # See
>>> http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html#index-alias
>>> READNULLCMD='less'      # Makes `< foo` do `less < foo`.
>>> alias -s txt='<' md='<' # .txt and .md files
>>> alias -s log='tail -f'  # .log files
>>
>> Letting the user type < for less is one thing, but you don't really
>> save anything by using a shorter command in the rhs of an alias... it
>> does doesn't allow the user to type more than one filename. eg:
>> % < file1 file2
>> zsh: command not found: file2
>> % less file1 file2
>> file1 (file 1 of 2) lines ?-?/? (END) - Next: file2
>
> There’s no harm in it, though, is there? Plus it makes it so you Don’t
> Repeat Yourself. Now you have only variable you need to change when you want
> to move from `less` to, say, `bat`.

I literally just showed a case where it is strictly worse for no gain
other than saving 3 bytes in the startup file. If you want a single
parameter to change, there is already $PAGER.

> On 6. Apr 2021, at 0.01, Mikael Magnusson <mikachu@gmail.com> wrote:
>>
>> On 4/5/21, Mikael Magnusson <mikachu@gmail.com> wrote:
>>>> bindkey "$key[Backtab]" reverse-menu-complete
>>>> bindkey -M menuselect -s "$key[Backtab]" "$key[Return]$key[Tab]"
>>
>> Also just noticed you have both of these, so if you press shift-tab
>> twice it will first do a reverse-menu-complete inserting the last
>> match, then if you press it again it accepts it and inserts the first
>> match.
>
> Yeah, perhaps those two don’t really make sense together. I would like there
> to be a completion menu shortcut that inserts the current selection and then
> immediately completes again, but that doesn’t really rhyme with
> reverse-menu-complete.

As mentioned above, this is accept-and-infer-next-history in menu
selection (maybe not interactive mode).

I realize that I have only made negative comments so far, but I'd like
to say that I appreciate that there's no huge list of arbitrary
aliases that nobody would ever know about anyway, and other crud
(looking at omz).

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-07 18:15   ` Mikael Magnusson
@ 2021-04-07 18:50     ` Daniel Shahaf
  2021-04-07 20:08     ` Arseny Maslennikov
  2021-04-09 20:07     ` Marlon
  2 siblings, 0 replies; 28+ messages in thread
From: Daniel Shahaf @ 2021-04-07 18:50 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Zsh hackers list, Marlon Richert

Mikael Magnusson wrote on Wed, 07 Apr 2021 18:15 +00:00:
> On 4/7/21, Marlon <marlon.richert@gmail.com> wrote:
> >> On 5. Apr 2021, at 22.44, Mikael Magnusson <mikachu@gmail.com> wrote:
> >> On 4/5/21, Marlon Richert <marlon.richert@gmail.com> wrote:
> >>> # Auto-save last 20 dirs to file whenever we change dirs.
> >>> # See
> >>> http://zsh.sourceforge.net/Doc/Release/User-Contributions.html#Recent-Directories
> >>> autoload -Uz add-zsh-hook chpwd_recent_dirs
> >>> add-zsh-hook chpwd chpwd_recent_dirs
> >>> zstyle ':chpwd:*' recent-dirs-file ${ZDOTDIR:-$HOME}/.chpwd-recent-dirs
> >>>
> >>> # On startup, initialize dir stack from file.
> >>> autoload -Uz chpwd_recent_filehandler
> >>> chpwd_recent_filehandler
> >>> cd $reply[1]
> >>> dirs $reply[@] >/dev/null
> >>
> >> Does this start zsh in some other directory than it inherited from the
> >> terminal? If so, nak from me on that, way too surprising.
> >
> > It makes the shell pick up in the same dir as where you left off last time.
> > I would hardly call that surprising. In fact, I would pretty much call that
> > _expected_ for most applications nowadays.
> 
> I think most people on the list will strongly disagree with you here.

Yes and no.  On the one hand, "start in the cwd of the shell last
closed" would just get in my way: if I close an xterm on virtual desktop
2, switch to virtual desktop 3, and pop open a new xterm, I'd rather it
opened in ~ then in the cwd of the shell I just closed.

On the other hand, one of the things I miss since I migrated from
xfce4-terminal to «tabbed -c xterm -into» (from suckless-tools) is that the
former would default new tabs to the cwd of whatever command was running
in the tab in focus.  That guess wasn't always right, because it used
(IIRC) the cwd of the "top-most" (process tree -wise) shell in the tab
even if from that shell I ran zsh/vim/tmux and that process's cwd was
different, but in general, if I wanted the default of ~ it was easy
enough to just type «cd» and move on.

But even then, the default cwd wasn't some "global" thing; it was the
cwd of the tab in focus.  cwd's of other tabs, or of tabs in other
xfce4-terminal windows, wouldn't factor in.

So, if there was some way to say "Look up the process tree to the thing
I'm in" — be that a tmux session, a tabbed terminal emulator window,
a virtual desktop (in the `wmctrl -d` sense), etc. — and use that as the
default cwd of new processes, I might use that…

… but that's not going to be easy to get right, and in any case I amn't
going as far as to say it'd be good for the default zshrc.  It's stateful
magic.  If anything, it sounds like something that should be handled
outside zsh, by having whatever invokes zsh cd() before exec()ing.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-07 18:15   ` Mikael Magnusson
  2021-04-07 18:50     ` Daniel Shahaf
@ 2021-04-07 20:08     ` Arseny Maslennikov
  2021-04-09 20:07     ` Marlon
  2 siblings, 0 replies; 28+ messages in thread
From: Arseny Maslennikov @ 2021-04-07 20:08 UTC (permalink / raw)
  To: Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 4191 bytes --]

On Wed, Apr 07, 2021 at 08:15:18PM +0200, Mikael Magnusson wrote:
> On 4/7/21, Marlon <marlon.richert@gmail.com> wrote:
> >
> >> On 5. Apr 2021, at 22.44, Mikael Magnusson <mikachu@gmail.com> wrote:
> >>
> >> On 4/5/21, Marlon Richert <marlon.richert@gmail.com> wrote:
> >>> #
> >>> # Type `zrestart` to safely apply changes after editing this file.
> >>> #
> >>> zrestart() {
> >>>  local zshrc=${ZDOTDIR:-$HOME}/.zshrc
> >>>  print -P "Validating %U$zshrc%u..."
> >>>  zsh -nf $zshrc ||
> >>>    return
> >>>
> >>>  print -P 'Restarting Zsh...'
> >>>  zsh -l &&
> >>>    exit
> >>> }

There are two problems with `zsh -l && exit':
1) every zrestart invocation as written consumes PID space (so not
really a restart);
2) if the last job of the last zsh in a zrestart chain has a non-zero
exit status (e. g. WIFSIGNALED or falsey), and that zsh is ordered to
exit, it will return that exit status, breaking the zrestart chain. The
user would likely interpret this as "wow, my ^D doesn't work!".

I don't know how to write zrestart in plain zsh robustly enough to be
worthy of inclusion in the default .zshrc. Personally I just do
    alias zz='exec zsh'
or
    alias ZZ='exec zsh'
and that's it, but that's too minimalistic for a newbie tool.

> >>
> >> This could be an autoloadable function, not pasted verbatim in .zshrc.
> >> Also disagree with -l here. You can use $options[login] or $- to see
> >> if you're in a login shell already and start same. Things like this we
> >> can't fix after users already copy this config. It should try to
> >> mostly be configuration, not helper functions that can have permanent
> >> flaws once installed.
> >
> > Sure, I can move it to an autoloadable function. That’s fine by me. I did
> > not come up with the -l, though. Earlier in the thread, Oliver & Bart didn’t
> > like using `exec zsh` and offered this instead. See
> > [48031](https://www.zsh.org/mla/workers/2021/msg00244.html). I’d be happy to
> > change it, but I don’t know how they feel about it.
> 
> You could also just have a comment saying something to the effect of
> "changes to this file will only take effect in new shells, you can
> either open a new terminal or type "zsh" in an existing terminal". I
> guess I don't care too much either way after all.
<...>
> >>> # Auto-save last 20 dirs to file whenever we change dirs.
> >>> # See
> >>> http://zsh.sourceforge.net/Doc/Release/User-Contributions.html#Recent-Directories
> >>> autoload -Uz add-zsh-hook chpwd_recent_dirs
> >>> add-zsh-hook chpwd chpwd_recent_dirs
> >>> zstyle ':chpwd:*' recent-dirs-file ${ZDOTDIR:-$HOME}/.chpwd-recent-dirs
> >>>
> >>> # On startup, initialize dir stack from file.
> >>> autoload -Uz chpwd_recent_filehandler
> >>> chpwd_recent_filehandler
> >>> cd $reply[1]
> >>> dirs $reply[@] >/dev/null
> >>
> >> Does this start zsh in some other directory than it inherited from the
> >> terminal? If so, nak from me on that, way too surprising.
> >
> > It makes the shell pick up in the same dir as where you left off last time.
> > I would hardly call that surprising. In fact, I would pretty much call that
> > _expected_ for most applications nowadays.
> 
> I think most people on the list will strongly disagree with you here.

Oh yes. When I was giving my (mostly positive or indifferent) feedback
to Marlon privately on his request, I just ignored this part about
dirstack at all, since I neither use it nor care about it.

Making the shell chdir to a different directory every time is incredibly
unintuitive to most Unix shell users.
The runtime state restore functionality expected from applications does not
apply here at all, because the shell is not an application, but a power
tool.
To expand on this: while a running application is usually a
singleton in a given system, it's not uncommon for people to run about
10-15 fully independent shells for different tasks simultaneously.
Consider the user logs out from such a session and then logs back in —
the next shell they start will chdir to a directory last changed to by
those 15 shells, and that directory is hard to keep track of.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-07 14:28 ` Marlon
                     ` (2 preceding siblings ...)
  2021-04-07 18:15   ` Mikael Magnusson
@ 2021-04-09 15:29   ` Marlon
  3 siblings, 0 replies; 28+ messages in thread
From: Marlon @ 2021-04-09 15:29 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Zsh hackers list


> On 7 Apr 2021, at 17:28, Marlon <marlon.richert@gmail.com> wrote:
> 
>>> # Add some basic command line highlighting.
>>> # See http://zsh.sourceforge.net/Doc/Release/Zsh-Line-Editor.html#Character-Highlighting
>>> zle_highlight=(
>>> isearch:fg=black,bg=yellow  # Matched search text
>>> paste:none                  # Yanked/pasted text
>>> region:bg=blue              # Selected text
>>> special:fg=cyan,bold        # Unprintable characters
>>> suffix:bg=blue              # Auto-removable suffix inserted by completion
>>> )
>> 
>> There are many colors, why use the same for the region and the suffix?
> 
> Because it’s familiar from the GUI world: If text looks selected, then you expect it to be replaced when you type over it.

Another reason: Because others in this thread have told me to avoid using anything else than the 8 basic terminal colors.




^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-07 18:15   ` Mikael Magnusson
  2021-04-07 18:50     ` Daniel Shahaf
  2021-04-07 20:08     ` Arseny Maslennikov
@ 2021-04-09 20:07     ` Marlon
  2021-04-09 22:04       ` Oliver Kiddle
  2021-04-09 23:23       ` Mikael Magnusson
  2 siblings, 2 replies; 28+ messages in thread
From: Marlon @ 2021-04-09 20:07 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Zsh hackers list


> On 7 Apr 2021, at 21:15, Mikael Magnusson <mikachu@gmail.com> wrote:
> You could also just have a comment saying something to the effect of
> "changes to this file will only take effect in new shells, you can
> either open a new terminal or type "zsh" in an existing terminal". I
> guess I don't care too much either way after all.

The problem is that many new users have learned from OMZ and other sources that they should do `source ~/.zshrc` to apply changes. I originally had a note that said you should instead either restart your terminal or type `exec zsh`, but then Oliver & Bart came up with the current solution.


>> Personally, I would’ve preferred `setopt HIST_IGNORE_ALL_DUPS
>> SHARE_HISTORY`, but there were several votes against that earlier in this
>> thread.
> 
> I'm glad, those are even worse :).

Why? What’s so bad about those?


> tab will insert the unambiguous part, and then start cycling
> (depending on your setopts, this takes anywhere from 0 to 4 or so tab
> presses).

Nope, in `interactive` mode, it just inserts the unambiguous part and that’s it.


> Well, I'd have the same objection to either of them, that it's quite a
> huge departure from the standard mode of operation which is typing
> normally and pressing tab to complete words.

I think it’s a great feature that very people actually know about. Besides that, even when using `interactive`, you’re still typing normally and pressing Tab to complete words. It doesn’t change that. Have you tried the feature?


>>>> bindkey -M menuselect -s "$key[Backtab]" "$key[Return]$key[Tab]"
>>> 
>>> How is this different from ^[a (eg, accept-and-hold) in menu selection?
>> 
>> accept-and-hold doesn’t work correctly with, for example, directory
>> completions. To see this for yourself, try `cd /` + Tab + ^[a. Then try `cd
>> /` + Tab + Backtab. Notice the difference. The first one makes no sense.
> 
> In that particular use case I think you would use accept-and-infer-next-history.

Nope, doesn’t work either. It inserts the selection but does not advance to the next completion.




^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-09 20:07     ` Marlon
@ 2021-04-09 22:04       ` Oliver Kiddle
  2021-04-09 23:04         ` Daniel Shahaf
  2021-04-09 23:08         ` Bart Schaefer
  2021-04-09 23:23       ` Mikael Magnusson
  1 sibling, 2 replies; 28+ messages in thread
From: Oliver Kiddle @ 2021-04-09 22:04 UTC (permalink / raw)
  To: Zsh hackers list

Marlon wrote:
>
> The problem is that many new users have learned from OMZ and other
> sources that they should do `source ~/.zshrc` to apply changes. I
> originally had a note that said you should instead either restart your
> terminal or type `exec zsh`, but then Oliver & Bart came up with the
> current solution.

Would it be better if we put the zrestart function in Functions/Misc
so the .zshrc only needs to contain autoload -U zrestart and a
comment to explain what it does?

Oliver


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-09 22:04       ` Oliver Kiddle
@ 2021-04-09 23:04         ` Daniel Shahaf
  2021-04-09 23:55           ` Bart Schaefer
  2021-04-09 23:08         ` Bart Schaefer
  1 sibling, 1 reply; 28+ messages in thread
From: Daniel Shahaf @ 2021-04-09 23:04 UTC (permalink / raw)
  To: zsh-workers

Oliver Kiddle wrote on Sat, Apr 10, 2021 at 00:04:02 +0200:
> Marlon wrote:
> >
> > The problem is that many new users have learned from OMZ and other
> > sources that they should do `source ~/.zshrc` to apply changes. I
> > originally had a note that said you should instead either restart your
> > terminal or type `exec zsh`, but then Oliver & Bart came up with the
> > current solution.
> 
> Would it be better if we put the zrestart function in Functions/Misc
> so the .zshrc only needs to contain autoload -U zrestart and a
> comment to explain what it does?

The points from workers/48434 would still be outstanding.

Cheers,

Daniel

P.S. Has the point been made that zrestart loses state?  E.g.,
variables/styles set won't persist through a zrestart.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-09 22:04       ` Oliver Kiddle
  2021-04-09 23:04         ` Daniel Shahaf
@ 2021-04-09 23:08         ` Bart Schaefer
  2021-04-10  7:44           ` Roman Perepelitsa
  1 sibling, 1 reply; 28+ messages in thread
From: Bart Schaefer @ 2021-04-09 23:08 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Zsh hackers list

On Fri, Apr 9, 2021 at 3:04 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> Marlon wrote:
> >
> > The problem is that many new users have learned from OMZ and other
> > sources that they should do `source ~/.zshrc` to apply changes.

Which is somewhat cringey for a number of out-of-scope reasons.

> > originally had a note that said you should instead either restart your
> > terminal or type `exec zsh`, but then Oliver & Bart came up with the
> > current solution.
>
> Would it be better if we put the zrestart function in Functions/Misc

That doesn't address whether we should employ $- or a conditional to
find flags to pass to the restarted shell, nor does it address
Arseny's concern about a shell in the "chain" having a nonzero exit
status.  (If use of the PID space is really an issue, the user is
restarting WAY too often.)

I somewhat hesitantly suggest (because I don't have a clear
implementation in mind yet) that perhaps the .zshrc should set a
variable to record that it has been run, and employ some conditional
test(s) to deal with being source'd a second+ time?


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-09 20:07     ` Marlon
  2021-04-09 22:04       ` Oliver Kiddle
@ 2021-04-09 23:23       ` Mikael Magnusson
  2021-04-10  7:45         ` Marlon Richert
  1 sibling, 1 reply; 28+ messages in thread
From: Mikael Magnusson @ 2021-04-09 23:23 UTC (permalink / raw)
  To: Marlon; +Cc: Zsh hackers list

On 4/9/21, Marlon <marlon.richert@gmail.com> wrote:
>
>> On 7 Apr 2021, at 21:15, Mikael Magnusson <mikachu@gmail.com> wrote:
>> You could also just have a comment saying something to the effect of
>> "changes to this file will only take effect in new shells, you can
>> either open a new terminal or type "zsh" in an existing terminal". I
>> guess I don't care too much either way after all.
>
> The problem is that many new users have learned from OMZ and other sources
> that they should do `source ~/.zshrc` to apply changes. I originally had a
> note that said you should instead either restart your terminal or type `exec
> zsh`, but then Oliver & Bart came up with the current solution.
>
>
>>> Personally, I would’ve preferred `setopt HIST_IGNORE_ALL_DUPS
>>> SHARE_HISTORY`, but there were several votes against that earlier in
>>> this
>>> thread.
>>
>> I'm glad, those are even worse :).
>
> Why? What’s so bad about those?

Typical worst case problem is you run a command, look at your
terminal, press up twice and enter, and you've accidentally deleted
your entire home directory.

>> Well, I'd have the same objection to either of them, that it's quite a
>> huge departure from the standard mode of operation which is typing
>> normally and pressing tab to complete words.
>
> I think it’s a great feature that very people actually know about. Besides
> that, even when using `interactive`, you’re still typing normally and
> pressing Tab to complete words. It doesn’t change that. Have you tried the
> feature?

I have tried it, but as you note:

> Nope, doesn’t work either. It inserts the selection but does not advance to
> the next completion.
[...]
> Nope, in `interactive` mode, it just inserts the unambiguous part and that’s
> it.

It doesn't work that well.

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-09 23:04         ` Daniel Shahaf
@ 2021-04-09 23:55           ` Bart Schaefer
  2021-04-13 15:00             ` Daniel Shahaf
  0 siblings, 1 reply; 28+ messages in thread
From: Bart Schaefer @ 2021-04-09 23:55 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

On Fri, Apr 9, 2021 at 4:07 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> P.S. Has the point been made that zrestart loses state?  E.g.,
> variables/styles set won't persist through a zrestart.

That's actually intentional, because those variables/styles would not
be present with a fresh shell anyway; if they were meant to persist
they should be in the zshrc.

However, it occurs to me that none of the proposals addresses making
sure that the history has been saved (history is not written upon
"exec" and would be saved in reverse order by unwinding a chain of new
shells).


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-09 23:08         ` Bart Schaefer
@ 2021-04-10  7:44           ` Roman Perepelitsa
  0 siblings, 0 replies; 28+ messages in thread
From: Roman Perepelitsa @ 2021-04-10  7:44 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Oliver Kiddle, Zsh hackers list

On Sat, Apr 10, 2021 at 1:08 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> I somewhat hesitantly suggest (because I don't have a clear
> implementation in mind yet) that perhaps the .zshrc should set a
> variable to record that it has been run, and employ some conditional
> test(s) to deal with being source'd a second+ time?

FWIW, this is what I've done in zsh4humans. An attempt to source
.zshrc results in an error message with a suggestion to use `exec
zsh`. It doesn't actually run the command so users who understand the
subtleties can run something else. This has worked well so far. I
regularly receive bug reports against powerlevel10k from users who run
`source .zshrc` and expect the same results as if they restarted zsh
but I never get those from zsh4humans users.

Roman.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-09 23:23       ` Mikael Magnusson
@ 2021-04-10  7:45         ` Marlon Richert
  0 siblings, 0 replies; 28+ messages in thread
From: Marlon Richert @ 2021-04-10  7:45 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Zsh hackers list


> On 10 Apr 2021, at 02:23, Mikael Magnusson <mikachu@gmail.com> wrote:
> I have tried it, but as you note:
> It doesn't work that well.

Then we should fix that (accept-line & accept-and-x behavior in complist interactive mode). It’s otherwise a great feature. 



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-07 16:24     ` Daniel Shahaf
@ 2021-04-10 11:23       ` Marlon
  2021-04-10 20:46         ` dana
  0 siblings, 1 reply; 28+ messages in thread
From: Marlon @ 2021-04-10 11:23 UTC (permalink / raw)
  To: Daniel Shahaf
  Cc: İsmail Dönmez, Arseny Maslennikov, Kamil Dudka,
	Zsh hackers list


> On 7 Apr 2021, at 19:24, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 
> I think there's a distinction to be drawn between "stuff we should
> enable in the default zshrc" and "cool stuff that people might want to
> use, or read to learn about useful tricks/features".
> 
> I agree with Mikael and Bart that most of your zshrc falls under the
> latter category.  That has its place (cf. Misc/vcs_info-examples), but
> it's too magical for the default.
> 
> That's also one of the standard criticisms against oh-my-zsh, by the way.

I have heard many criticism against OMZ, but it being “too magical” is new to me. What exactly do you mean with that?


>> Some quotes:
>> 
>> "this zshrc offers a lot of tricks I personally wanted to use but didn't know they were already implemented; thanks a lot for shining a light on them!”
>> 
>> "I gave it a spin and it looks very nice, much less scary than the default one. I've checked the default .zshrc and it looks fine to me."
> 
> If the author of the second quote wishes to join this thread, they're of
> course welcome to do so.  They might change their opinion, or change
> ours.

I’ve now CC’d them, plus the others from which I’ve gotten feedback, on this email.



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-10 11:23       ` Marlon
@ 2021-04-10 20:46         ` dana
  2021-04-10 21:41           ` Bart Schaefer
  2021-04-13 14:55           ` Daniel Shahaf
  0 siblings, 2 replies; 28+ messages in thread
From: dana @ 2021-04-10 20:46 UTC (permalink / raw)
  To: Marlon; +Cc: Zsh hackers list

On 10 Apr 2021, at 06:23, Marlon <marlon.richert@gmail.com> wrote:
> I have heard many criticism against OMZ, but it being “too magical” is new
> to me. What exactly do you mean with that?

Isn't it the *primary* criticism of OMZ? Most of its users seem to have zero
understanding of what it does or what separates it from zsh itself.

***

Aside from being busy, i've kind of stepped back from this project because
i've started to have some anxiety about it myself. Although i still feel we
can't be *too* minimalistic with a default config, since nobody would use it,
the proposed changes have gone beyond the scope i'd initially envisioned. At
the same time, i don't know how to make an 'objective' case for why x change
is desirable but y change is excessive.

I will say that we talked about this a bit on IRC (which is what prompted
Mikael to respond) and it seemed like most of the people in that discussion
felt that the proposed configuration is too complex to be of much help with
the stated goal of demonstrating how new users can modify their own config. I
hope it's not too arrogant to say, but it feels like if i as a zsh developer
don't understand what a lot of the config does without looking it up, it's
going to be nearly indecipherable to a beginner.

That ties in with another concern i have, which is that once a user installs
this configuration, it's basically untouchable to us. We can't really patch it
after the fact if there's a problem with it. The more complex the config is,
the greater the risk that we'll have an issue like that.

Those two observations lead me to feel that, if we do go forward with this,
maybe implementing it with prompt styles and auto-loaded functions would be
the way to go after all. That would hide some of the more overwhelming aspects
of the config from end users, and it would allow us to patch bugs or otherwise
improve things after the fact.

I feel silly for bringing up fundamental 'architecture' questions so late in
the game but maybe that's something that we should come to a consensus on
before we finalise exactly what options/styles/whatever will be set.

dana



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-10 20:46         ` dana
@ 2021-04-10 21:41           ` Bart Schaefer
  2021-04-10 22:03             ` Roman Perepelitsa
  2021-04-13 14:55           ` Daniel Shahaf
  1 sibling, 1 reply; 28+ messages in thread
From: Bart Schaefer @ 2021-04-10 21:41 UTC (permalink / raw)
  To: dana; +Cc: Marlon, Zsh hackers list

On Sat, Apr 10, 2021 at 1:47 PM dana <dana@dana.is> wrote:
>
> the proposed changes have gone beyond the scope i'd initially envisioned.

Ditto.

> the proposed configuration is too complex to be of much help with
> the stated goal of demonstrating how new users can modify their own config.

This is also my feeling.

> That ties in with another concern i have, which is that once a user installs
> this configuration, it's basically untouchable to us. We can't really patch it
> after the fact if there's a problem with it.

Not if the user is encouraged to edit it in place, anyway.

> Those two observations lead me to feel that, if we do go forward with this,
> maybe implementing it with prompt styles and auto-loaded functions would be
> the way to go after all.

This is venturing into the territory of "should zsh ship with a
preferred module management system"?  Because we're demonstrating a
use case for modules, here, which we haven't previously had any need
for.  If everything we want CAN be done with autoloaded functions, of
course, that's as "modular" as we need to get.

> I feel silly for bringing up fundamental 'architecture' questions so late in
> the game

It wasn't clear, early on, that the scope of the changes would require
architecting.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-10 21:41           ` Bart Schaefer
@ 2021-04-10 22:03             ` Roman Perepelitsa
  2021-04-11 11:38               ` Marlon Richert
  2021-04-13 14:49               ` Daniel Shahaf
  0 siblings, 2 replies; 28+ messages in thread
From: Roman Perepelitsa @ 2021-04-10 22:03 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: dana, Marlon, Zsh hackers list

On Sat, Apr 10, 2021 at 11:42 PM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> On Sat, Apr 10, 2021 at 1:47 PM dana <dana@dana.is> wrote:
> >
> > the proposed changes have gone beyond the scope i'd initially envisioned.
>
> Ditto.

Likewise. I've stopped commenting on this thread when it became
apparent that the size and complexity of the default zshrc I had in
mind is an order of magnitude lower than what's being discussed.

In my opinion, if zsh were to ship with a default zshrc (or generate
one via a wizard), it must be REALLY simple and REALLY short. If
someone wants to define a better zshrc with more functionality, let
them do so and compete with oh-my-zsh. It's much better for the
default zshrc to be too conservative than too complex.

Roman.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-10 22:03             ` Roman Perepelitsa
@ 2021-04-11 11:38               ` Marlon Richert
  2021-04-13 14:49               ` Daniel Shahaf
  1 sibling, 0 replies; 28+ messages in thread
From: Marlon Richert @ 2021-04-11 11:38 UTC (permalink / raw)
  To: Roman Perepelitsa, Bart Schaefer, dana; +Cc: Zsh hackers list


> On 11 Apr 2021, at 01:03, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
> 
> On Sat, Apr 10, 2021 at 11:42 PM Bart Schaefer
> <schaefer@brasslantern.com> wrote:
>> 
>>> On Sat, Apr 10, 2021 at 1:47 PM dana <dana@dana.is> wrote:
>>> 
>>> the proposed changes have gone beyond the scope i'd initially envisioned.
>> 
>> Ditto.
> 
> Likewise. I've stopped commenting on this thread when it became
> apparent that the size and complexity of the default zshrc I had in
> mind is an order of magnitude lower than what's being discussed.

Looking at the .zshrc I’ve made, I would suggest the following changes to reduce its length and complexity:
* Move zrestart() to an autoloadable function. This is done. I just need to push it in.
* Move the prompt code into a theme that can be customized easily. This is done, too, and will be pushed.
* Move Home, End, Alt-Right/Left & Alt-Delete key bindings to the ZLE code and menuselect Alt-Up/Down + Page Up/Down keybindings to complist. This not done yet.
* Fix the way Tab behaves in complist interactive mode. Not done yet.
* Move the rest of the keybinding code to an autoloadable function. Not done.
* Make a “theme” system for compsys. We could put a couple of different flavors of comp config into comp themes: one for menu select haters, ;) one that uses `interactive` type-ahead, etc. Alternatively, split the settings into several modular, autoloadable functions, so users can mix and match. Neither of these is done yet.
* Create an autoloadable function for the pushd/cd widgets. Done & will be pushed.





^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-10 22:03             ` Roman Perepelitsa
  2021-04-11 11:38               ` Marlon Richert
@ 2021-04-13 14:49               ` Daniel Shahaf
  1 sibling, 0 replies; 28+ messages in thread
From: Daniel Shahaf @ 2021-04-13 14:49 UTC (permalink / raw)
  To: zsh-workers

Roman Perepelitsa wrote on Sun, Apr 11, 2021 at 00:03:18 +0200:
> On Sat, Apr 10, 2021 at 11:42 PM Bart Schaefer
> <schaefer@brasslantern.com> wrote:
> >
> > On Sat, Apr 10, 2021 at 1:47 PM dana <dana@dana.is> wrote:
> > >
> > > the proposed changes have gone beyond the scope i'd initially envisioned.
> >
> > Ditto.
> 
> Likewise. I've stopped commenting on this thread when it became
> apparent that the size and complexity of the default zshrc I had in
> mind is an order of magnitude lower than what's being discussed.
> 
> In my opinion, if zsh were to ship with a default zshrc (or generate
> one via a wizard), it must be REALLY simple and REALLY short. If
> someone wants to define a better zshrc with more functionality, let
> them do so and compete with oh-my-zsh. It's much better for the
> default zshrc to be too conservative than too complex.

May I mention zsh-sensible (the original one) again?  Here's its zshrc
with comments removed:

[[[
PS1="%m:%~%# "
setopt INTERACTIVE_COMMENTS
HISTSIZE=1000
SAVEHIST=1000
HISTFILE=${XDG_CACHE_HOME:-"${HOME}/.cache"}/zsh_history
autoload -Uz compinit && compinit
zstyle ':completion:*' group-name ''
zstyle ':completion:*' format '>>> %d'
autoload -Uz add-zsh-hook
autoload -Uz vcs_info
_precmd_vcs_info() {
	vcs_info
	if [[ -n ${vcs_info_msg_0_} ]]; then
		print -P -r -- ${vcs_info_msg_0_}
	fi
}
add-zsh-hook precmd _precmd_vcs_info
bindkey -e
]]]


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-10 20:46         ` dana
  2021-04-10 21:41           ` Bart Schaefer
@ 2021-04-13 14:55           ` Daniel Shahaf
  1 sibling, 0 replies; 28+ messages in thread
From: Daniel Shahaf @ 2021-04-13 14:55 UTC (permalink / raw)
  To: zsh-workers

dana wrote on Sat, Apr 10, 2021 at 15:46:57 -0500:
> Aside from being busy, i've kind of stepped back from this project because
> i've started to have some anxiety about it myself. Although i still feel we
> can't be *too* minimalistic with a default config, since nobody would use it,
> the proposed changes have gone beyond the scope i'd initially envisioned. At
> the same time, i don't know how to make an 'objective' case for why x change
> is desirable but y change is excessive.

Why need it be objective?  If there's consensus on this list that
something should be added, add it; else, leave it out.  That's a high
bar, so it'll keep the result conservative/minimal.

> That ties in with another concern i have, which is that once a user installs
> this configuration, it's basically untouchable to us. We can't really patch it
> after the fact if there's a problem with it. The more complex the config is,
> the greater the risk that we'll have an issue like that.
> 
> Those two observations lead me to feel that, if we do go forward with this,
> maybe implementing it with prompt styles and auto-loaded functions would be
> the way to go after all. That would hide some of the more overwhelming aspects
> of the config from end users, and it would allow us to patch bugs or otherwise
> improve things after the fact.
> 

We could have, say, an autoloaded function called zsh-defaults, and have
the default zshrc consist of a (possibly commented-out) call to that
function.  That's similar to what Vim does nowadays, with
a «defaults.vim» runtime file that people can choose to source.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Rewrite of zsh-newuser-install (Mikael's subthread)
  2021-04-09 23:55           ` Bart Schaefer
@ 2021-04-13 15:00             ` Daniel Shahaf
  0 siblings, 0 replies; 28+ messages in thread
From: Daniel Shahaf @ 2021-04-13 15:00 UTC (permalink / raw)
  To: zsh-workers

Bart Schaefer wrote on Fri, Apr 09, 2021 at 16:55:40 -0700:
> On Fri, Apr 9, 2021 at 4:07 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > P.S. Has the point been made that zrestart loses state?  E.g.,
> > variables/styles set won't persist through a zrestart.
> 
> That's actually intentional, because those variables/styles would not
> be present with a fresh shell anyway; if they were meant to persist
> they should be in the zshrc.
> 
> However, it occurs to me that none of the proposals addresses making
> sure that the history has been saved (history is not written upon
> "exec"

exec does write history (in my setup, anyway).

>  and would be saved in reverse order by unwinding a chain of new
> shells).

Yeah, it's a bit annoying that history is saved in order the shells were
closed, rather than in chronological order of the commands.  E.g., if
shell pid=42 ran a command at noon and shell pid=43 ran a command at
13:00, and I exit 43 before 42, I'd still like the commands to be
written in that order.

I don't have EXTENDED_HISTORY set, though…

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2021-04-13 15:00 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-05 19:44 Rewrite of zsh-newuser-install (Mikael's subthread) Mikael Magnusson
2021-04-05 21:01 ` Mikael Magnusson
2021-04-05 21:44 ` Bart Schaefer
2021-04-07 13:44   ` Marlon
2021-04-07 16:24     ` Daniel Shahaf
2021-04-10 11:23       ` Marlon
2021-04-10 20:46         ` dana
2021-04-10 21:41           ` Bart Schaefer
2021-04-10 22:03             ` Roman Perepelitsa
2021-04-11 11:38               ` Marlon Richert
2021-04-13 14:49               ` Daniel Shahaf
2021-04-13 14:55           ` Daniel Shahaf
2021-04-07 14:28 ` Marlon
2021-04-07 15:14   ` Daniel Shahaf
2021-04-07 16:36   ` Bart Schaefer
2021-04-07 18:15   ` Mikael Magnusson
2021-04-07 18:50     ` Daniel Shahaf
2021-04-07 20:08     ` Arseny Maslennikov
2021-04-09 20:07     ` Marlon
2021-04-09 22:04       ` Oliver Kiddle
2021-04-09 23:04         ` Daniel Shahaf
2021-04-09 23:55           ` Bart Schaefer
2021-04-13 15:00             ` Daniel Shahaf
2021-04-09 23:08         ` Bart Schaefer
2021-04-10  7:44           ` Roman Perepelitsa
2021-04-09 23:23       ` Mikael Magnusson
2021-04-10  7:45         ` Marlon Richert
2021-04-09 15:29   ` Marlon

zsh-workers

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-workers

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-workers zsh-workers/ http://inbox.vuxu.org/zsh-workers \
		zsh-workers@zsh.org
	public-inbox-index zsh-workers

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git