[Pkg-zsh-devel] Bug#794967: zsh: please enhance /etc/zshrc

[Carsten Hey]

* Frank Terbeck [2015-08-08 23:46 +0200]:
> Carsten Hey wrote:
> [...]
> >  * Please add some additional keybindings, at least for the emacs keymap:
> >
> >    - bind PageUp "${terminfo[kpp]}" to history-search-backward
> >    - bind PageDown "${terminfo[knp]}" to history-search-forward
> >    - bind BackTabKey "${terminfo[kcbt]}" to reverse-menu-complete
>
> I firmly believe, that a vendor's *global* setup file should be as
> minimal as possible, which is why I really don't want to add anything
> that's more than making the zsh defaults behave more robustly across
> multiple terminals or deal with stuff specific to Debian.

It looks like you changed your opinion since you wrote
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622933#10

> >      In terminfo(5), the capname cbt is described as "back tab (P)"
> >      and kcbt is described as "back-tab key", therefore the suggested
> >      'BackTabKey' instead of 'BackTab' - even though grml confuses
> >      people that know terminfo(5) by using 'BackTab' as name.
>
> By that logic, kpp would need to be mapped to "PreviousPageKey". I think
> the current naming is fine.

No, there is no such name collusion with kpp.  What would be the name of
cbt if kcbt is BackTab?  Actually, the name does not matter ;)

> >      ...
> >
> >    - Red Hat maps or mapped space to magic-space, I think Debian should
> >      _not_ do this, but initially I thought that this would be a good
> >      idea.
>
> Again, this fits into the recommended setup file

The difference is that Red Hat destroys or destroyed existing mappings
with binding Space to magic-space.  Binding BackTab, which is unbound by
default, does not annoy or harm anybody.  The same applies to PageUp and
PageDown.  Nothing you wrote changed my opinion that BackTab, PageUp and
PageDown should by bound to something useful by default.

> >  * $key should be unset unless there is a reason for not doing so.
>
> The reason I left it set, is because its layout matches the $key
> dictionary, that zsh's "zkbd" function produces and can be used as a
> drop-in replacement. I still think that's a reasonable idea, even though
> it slightly violates the "A vendor's global setup needs to be minimal"
> rule.

If you can imagine a real world use case and nobody complains, it's fine :)

> >  * (( ${+aliases[run-help]} )) requires the zsh/parameter module.  If,
> >    in rare cases, possibly involving zsh-static, there is a chance that
> >    this module is not loaded successfully, you should consider doing
> >    this instead to remove the alias w/o error message:
> >
> >      alias run-help=
> >      unalias run-help
>
> That's a good point. I think we can do it like this:
>
>     unhash -a -m 'run-help' || true
>
> -a removes alias from its hash table. -m uses the argument as a pattern.
> Since there's no character that's significant to pattern matching, this
> will work. This way, there is no error message. The '|| true' is to make
> sure the setup file exits with successful status.

A sole : as last line instead of appending '|| true' to the last command
would make this intension more clear.

> We could also just do this:
>
>     unalias run-help 2>/dev/null || true
>
> …if that's more straight-forward to read.

If there is a reason to write something in a way that is less
straight-forward to read, one could add a comment that explains the
code.

debootstrap --foreign ... enters a chroot without /dev/null, there might
be other rare but valid cases where /dev/null is not available.
Normally this is not a problem (everybody does this, POSIX allows it,
...), but I'd like to avoid such things in default shell rc files and
especially in global shell rc files to avoid issues in rare corner
cases.


Carsten