8-bit parameter names?

[Bart Schaefer <schaefer@brasslantern.com>]

Is it intentional that 8-bit characters can be used in parameter name
identifiers, or is it a bug?

I was just looking at prompt_elite2_setup again, which has this comment:

 Recommended fonts for this theme: nexus or vga or similar.  If you
 don't have any of these, the 8-bit characters will probably look stupid.

In fact, the 8-bit characters don't look like anything at all, because
they're never displayed.  They're never displayed because the assingment
to PS1 is full of stuff like "$punctuation_colorU$textA..." where I've
replaced an 8-bit U-with-acute and A-with-umlaut with ascii U and A for
mailing list sanity.

The parameter code is treating e.g. U-with-acute as a valid part of the
identifier and finding no such parameter, so large parts of the elite2
prompt have simply been disappearing.  (If set_prompt didn't execute
"emulate -L zsh" (which turns off the "nounset" option) this would have
been much easier to catch.)

The prompt_elite2_setup function, meanwhile, was apparently meant all
along to be as follows; not sent as a patch because again I'm avoiding
sending 8-bit characters to the mailing list.


prompt_elite2_setup () {
  local text_col=${1:-'cyan'}
  local parens_col=${2:-$text_col}

  for code in 332 304 300; do
    local varname=char_$code
    : ${(P)varname=$(echo -n "\\0$code")}
  done

  local text="%{$fg_no_bold[$text_col]%}"
  local parens="%{$fg_bold[$parens_col]%}"
  local punct="%{$fg_bold[grey]%}"
  local reset="%{$reset_color%}"

  local lpar="$parens($text"
  local rpar="$parens)$text"

  PS1="$punct$char_332$text$char_304$lpar%n$punct@$text%m$rpar$char_304$lpar%!$punct/$text%y$rpar$char_304$lpar%D{%I:%M%P}$punct:$text%D{%m/%d/%y}$rpar$char_304$punct-$reset$prompt_newline$punct$char_300$text$char_304$lpar%#$punct:$text%~$rpar$char_304$punct-$reset " 

  PS2="$parens$char_304$text$char_304$punct-$reset "

  precmd () { setopt promptsubst }
  preexec () { }
}