Package: zsh
Severity: wishlist
Hi,
there is an additional, related, bug report in this one. The actual bug
report starts below the three dashes.
If I use the color-enabling "zstyle ':vcs_info:*' formats" string from
zshcontrib(1), it does not only add colors, but also slightly modifies
the format. In the example below, a space is removed and a minus is
replaced with a space. I would expect that such an documented example
format only modifies the colors - but YMMV.
~% setopt prompt_percent prompt_subst
~% autoload -Uz add-zsh-hook vcs_info
~% add-zsh-hook precmd vcs_info
~% PROMPT='%~$vcs_info_msg_0_%# '
~% cd gittest
~/gittest (git)-[master]-% zstyle ':vcs_info:*' formats
'%F{5}(%f%s%F{5})%F{3}-%F{5}[%F{2}%b%F{5}]%f '
~/gittest(git)-[master] %
The above format string without the trailing space is used (if
uncommented) in the improved newuser.zshrc.recommended and I think at
least in this file should a format string be used that only adds colors
and changes nothing else. OTOH, I think the default trailing minus does
not make that much sense, but I also assume that it won't be removed.
Anyway this detail of the improved newuser.zshrc.recommended can still
be changed in future.
The same possible documentation issue might, or might not, apply to the
example actionformats and branchformat strings.
It would be great if there would be a way to get a colorful vcs_info
without copying around (or alternatively, understanding) format strings;
for example running vcs_info --setup-only --enable-colors could set up
colorful format strings, but not execute vcs_info's vcs foo. Such
options could be used in the improved newuser.zshrc.recommended. The
obvious generalisation of --enable-colors is adding support for themes
that can be enabled via command line option.
---
Clint did a great job with his newuser.zshrc.recommended, he even added
proper integration into zsh upstream and added instructions for
inexperienced users (Hit TAB ...). Anyway, there are still some small
issues that could be fixed and things that could be improved (I might
have missed to list some things I changed):
* On white terminals, the recommended prompt for new users looks like
the broken hourly cron syslog entry - both contain three characters
equivalent to spaces in a row. The obvious fix for the prompt is
not using white text on white background.
* On white terminals, default foreground color on blue background is
suboptimal too, white on blue is way better.
* There is no (non-insane) way to add vcs_info to the used adam1
prompt.
* debian_chroot support is missing and can't easily be added to the
used prompt either.
* An exit code != 0 is not displayed, but IMHO this is useful. There
are two common ways how this is done, either added to the prompt in
some way, or using printexitvalue (known from tcsh) - I prefer the
latter.
* Menu select is only enabled if there are a lot of matches, I first
assumed that this might be a bug, but it looks like this was done by
intension. I agree that it is more useful if there are a lot of
matches, but it is still useful otherwise; and either always
enabling or always disabling this feature makes zsh feel more
consistent.
* A completion with _correct and _approximate might be useful for some
users and confuse others - presumably especially long time
unix/linux users, but also some new users don't expect their shell
to behave like a desktop word processor. I think such a feature
should be out-in.
* Some default aliases could be useful, at least ll seems to be used
all around. I also added h=history. l and la could be added too.
* The .zshrc could use a layout that is more consistent to itself and
zshall(1):
+ One comment line ends with a colon (I think I wrote this line),
the others don't.
+ History related options and history related variables should be
part of the same part of the file, but are split by bindkeys -e.
+ One comment is followed by an empty line, others don't.
+ zshall(1) writes option names with _ between the words, which
improves readability, and, if used the same way in a .zshrc,
eases searching for the option in the man page.
The two files can be found at:
http://stateful.de/~carsten/tmp/150717QVwIxjFQx9U/prompt_debian_setup
http://stateful.de/~carsten/tmp/150717QVwIxjFQx9U/newuser.zshrc.recommended
prompt_debian_setup should be submitted for inclusion in zsh after being
added to Debian's zsh.
The design and the source code of prompt_debian_setup was originally
based on prompt_adam1_setup and there might still be some lines from it.
Anything copyrightable (if there is something copyrightable in it at
all) in it that is not copied from prompt_adam1_setup is published under
the most liberal, public domain equivalent, license possible. On
request, I'll assign copyright to zsh's upstream. The changes I did to
newuser.zshrc.recommended are obviously not copyrightable - choose
a license of your choice if you disagree.
Since promptinit lacks a way to check if a prompt is available,
(( ${+prompt_themes[(r)debian]} )) is used to check this with a fallback to
adam1. After the next Debian release this line could be replaced with
"prompt debian".
actionformats and branchformat are missing in newuser.zshrc.recommended
since they would add clutter to it, and this .zshrc is not intended as
main .zshrc of people that need such things. vcs_info is also disabled
by default, which lowers the need to add these format strings.
There are different ways to use colors in zsh prompts, I randomly choose
one. This choice might be suboptimal and changing it might make sense.
The color foo that adds 255 or 256 aliases in a loop would presumably be
the wrong choice. I noticed that %b is not sufficient to end %K and %F
in a robust way.
2 vcs_info variables are used in PROMPT (since the default for
max-exports is 2), the second one might make sense as RPROMPT or
appended to the first one (i.e., remove the space with default
background). Knowing what the intension of this second variable is
might help to judge this.
All changes I made were done for a reason, even if they include "I don't
fully understand how KSH_ARRAYS influences zsh's parser" and "being set
-e safe can't be wrong". Please consider discussing additional changes
you might do before the initial commit in this bug report or on IRC.
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
