Re: Rewrite of zsh-newuser-install

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Marlon Richert wrote on Sat, Feb 27, 2021 at 00:31:27 +0200:
> On Thu, Feb 25, 2021 at 10:05 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > In general, there's <https://repology.org/project/zsh/versions>, but
> > I don't think we should rely on it.  If we have a question to downstream
> > maintainers, we should ask it on an appropriate mailing list — e.g.,
> > -workers@, or workers@ with an appropriate subject prefix/tag, or as
> > a drive-by mention in the next email to announce@.
> >
> > In this specific case, however, which downstreams actually ship
> > a recommended zshrc?  I suspect few do, so we can contact them directly.
> > For Debian, we should address our questions to pkg-zsh-devel
> > alioth-lists.debian.net.  (Those already familiar with bugs.debian.org
> > incantations may prefer to create a bug with X-Debbugs-Cc instead.)
> 
> Since I have little experience with downstream packagers, I'll leave
> it up to you to contact them. However, it would be great if you could
> CC me in the correspondence, so I can read their feedback first-hand.

They're just people.  They maintain glue code that ties their distro's
build system (ports(7), deb, rpm, …) to our tarballs, as well as any
custom patches or configuration their distro uses.  If you have
a question for them, you can drop them a line and ask, or start a thread
here and then drop them a line to make sure they're aware of it (not all
downstream maintainers necessarily follow -workers@ closely).

In the latter case I'd recommend to use some subject tag that downstream
maintainers can simply filter their -workers@ subscription for on an
ongoing basis, in order to remove the need for manual notifications in
the future.

> In the meantime, here's another update to the code for you to review:
> https://gitlab.com/marlonrichert/zsh-sensible/-/commit/799be4eccb870b5fc7b8563008e4b2547448ab40?w=1

Here's another bit of code that might be useful:

if zmodload zsh/complist 2>/dev/null || (( ${+keymaps[(r)menuselect]} )); then
  # vi mode for menu selection
  bindkey -M menuselect j down-line-or-history
  bindkey -M menuselect k up-line-or-history
  bindkey -M menuselect h backward-char
  bindkey -M menuselect l forward-char
  # Make <space> accept the completion-so-far,
  bindkey -M 'menuselect' ' ' accept-line # same binding as ^M,^J; and see above
fi

I haven't actually