8-bit parameter names?

8-bit parameter names?

[Bart Schaefer]

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 () { }
}

Re: 8-bit parameter names?

[Peter Stephenson]

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

There's a weird assumption that 8-bit characters from 160 can be treated
as alphanumeric.   This doesn't really work for any character set I'm
aware of.

    for (t0 = 0240; t0 != 0400; t0++)
	typtab[t0] = IALPHA | IALNUM | IIDENT | IUSER | IWORD;

Arguably we could just delete that.  The internal tests ialpha and
ialnum are used very infrequently in cases where use of an 8-bit
character isn't likely---they are not used to replace isalpha() and
isalnum() in pattern matching.  I don't know what characters you can
have in user names, but it's only used to test what follows a ~.  iword
needs redoing completely for Unicode anyway; we need to base it on
WORDCHARS plus isalnum() or iswalnum, a fixed table entry isn't good
enough.  (The [[:WORD:]] test I just added suffers from this too, but it
is at least consistent with zle which is its main purpose.)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: 8-bit parameter names?

[Clint Adams]

> needs redoing completely for Unicode anyway; we need to base it on
> WORDCHARS plus isalnum() or iswalnum, a fixed table entry isn't good
> enough.  (The [[:WORD:]] test I just added suffers from this too, but it

I tried to do this with wcschr(), but it broke completion like crazy.
Then I lost the patch.

Anyone have a better way of doing it?

Re: 8-bit parameter names?

[Bart Schaefer]

On May 9,  6:49pm, Peter Stephenson wrote:
}
} I don't know what characters you can have in user names, but it's only
} used to test what follows a ~.

Ah, well, that's probably how it got in there, then.  I'm sure there are
usernames with non-ascii characters in non-English-speaking countries.
Unfortunate side-effect that it also affects variable names.

} iword needs redoing completely for Unicode anyway; we need to base it
} on WORDCHARS plus isalnum() or iswalnum

While you're at it, keep in mind that it'd be nice to be able to parse
a dot as a valid parameter name character, but only within ${ } braces.
Ksh namespace syntax and all that.