Re: Rewrite of zsh-newuser-install (Mikael's subthread)

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 4/7/21, Marlon <marlon.richert@xxxxxxxxx> wrote:
>
>> On 5. Apr 2021, at 22.44, Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>>
>> On 4/5/21, Marlon Richert <marlon.richert@xxxxxxxxx> 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@xxxxxxxxx> wrote:
>>
>> On 4/5/21, Mikael Magnusson <mikachu@xxxxxxxxx> 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