PATCH: Enhancing math expressions a bit

PATCH: Enhancing math expressions a bit

[Sven Wischnowsky]

I was finally tired of using tests like [[ '#key' -eq 8 ]], so this
changes getkeystring() so that it can also parse only one character
(btw, maybe we should turn the `fromwhere' argument into a flags
argument and add some constants some day). The it makes math mode use
this function to get the ASCII-value of a character. I.e. you can now
say [[ '#key' -eq '#\\C-h' ]] and things like that.

I'm not sure if this is the way to go, but the change to
getkeystring() may be interesting to have in other places to and the
change in math.c is then trivial. I was first thinking about an option 
for `read' so that it returns strings like `C-h', dunno if this is
better. If we once agree to use this patch, we should probably change
the `keys' special parameter to a special scalar with just the literal 
characters. Maybe we should also add an option to some builtin to get
a human-readable form for the n'th character.

Ok, with the last patch and the one below, I hacked these two widgets
(they are probably a bit silly). I was tempted to put them into files
in a directory `Widgets' and stick something like `#widdef' or
`#zledef' in front, as if we were able to auto-autoload such things. I 
would really like to generalise the completion-auot-loading code some
day...

This allows you to type a file-pattern step by step and displays all
matching files below the prompt. Hitting return inserts all matched
files in the command line. I just wanted to test the list-display-code.

zle -N insert-files
insert-files() {
  local key str files

  files=( *(N) )
  if (( $#files )); then
    zle -R "files: ${str}_" "$files[@]"
  else
    zle -R "files: ${str}_ (failed)"
  fi
  read -k key
  while [[ '#key' -ne '#\\r' && '#key' -ne '#\\n' &&
           '#key' -ne '#\\C-g' ]]; do
    if [[ '#key' -eq '#\\C-h' || '#key' -eq '#\\C-?' ]]; then
      [[ -n "$str" ]] && str="$str[1,-2]"
    else
      str="$str$key"
    fi
    files=( ${~str}*(N) )
    if (( $#files )); then
      zle -R "files: ${str}_" "$files[@]"
    else
      zle -R "files: ${str}_ (failed)"
    fi
    read -k key
  done
  zle -Rc
  if [[ '#key' -ne '#\\C-g' && $#files -gt 0 ]]; then
    [[ "$LBUFFER[-1]" = ' ' ]] || files=('' "$files[@]")
    LBUFFER="$LBUFFER$files "
  fi
}


Is your machine fast enough? If so you can try this one. Just start it 
and it will attempt completion after every character you type, showing 
the list of matches. There are even some configuration keys, although
it should work with compctl, too.

zle -N incremental-complete-word
incremental-complete-word() {
  local key lbuf="$LBUFFER" rbuf="$RBUFFER" pmpt

  [[ -n "$compconfig[incremental_completer]" ]] &&
      set ${(s.:.)compconfig[incremental_completer]}
  pmpt="${compconfig[incremental_prompt]-incremental completion...}"

  zle list-choices
  zle -R "$pmpt"
  read -k key

  while [[ '#key' -ne '#\\r' && '#key' -ne '#\\n' &&
           '#key' -ne '#\\C-g' ]]; do
    if [[ "$key" = ${~compconfig[incremental_stop]} ]]; then
      zle -U "$key"
      return
    elif [[ "$key" = ${~compconfig[incremental_break]} ]]; then
      return
    elif [[ '#key' -eq '#\\C-h' || '#key' -eq '#\\C-?' ]]; then
      [[ $#LBUFFER -gt $#l ]] && LBUFFER="$LBUFFER[1,-2]"
    elif [[ '#key' -eq '#\\t' ]]; then
      zle complete-word "$@"
    else
      LBUFFER="$LBUFFER$key"
    fi
    zle list-choices "$@"
    zle -R "$pmpt"
    read -k key
  done
  if [[ '#key' -eq '#\\C-g' ]]; then
    LBUFFER="$lbuf"
    RBUFFER="$rbuf"
  fi
  zle -Rc
}

Bye
 Sven

diff -u -r kos/math.c Src/math.c
--- kos/math.c	Wed Jul  7 09:13:15 1999
+++ Src/math.c	Wed Jul  7 09:14:55 1999
@@ -357,9 +357,11 @@
 	    }
 	    if (*ptr == '#') {
 		if (*++ptr == '\\') {
+		    int v;
+
 		    ptr++;
-		    yyval = *ptr == Meta ? *++ptr ^ 32 : *ptr;
-		    ptr++;
+		    ptr = getkeystring(ptr, NULL, 6, &v);
+		    uuval = v;
 		    unary = 0;
 		    return NUM;
 		}
diff -u -r kos/utils.c Src/utils.c
--- kos/utils.c	Wed Jul  7 09:13:16 1999
+++ Src/utils.c	Wed Jul  7 09:13:49 1999
@@ -3187,24 +3187,28 @@
  *   4:  Do $'...' quoting.  Overwrites the existing string instead of
  *       zhalloc'ing 
  *   5:  As 2, but \- is special.  Expects misc to be defined.
+ *   6:  As 2, but parses only one character and returns end-pointer
+ *       and parsed character in *misc
  */
 
 /**/
 char *
 getkeystring(char *s, int *len, int fromwhere, int *misc)
 {
-    char *buf;
+    char *buf, tmp[1];
     char *t, *u = NULL;
     char svchar = '\0';
     int meta = 0, control = 0;
 
-    if (fromwhere != 4)
-	buf = zhalloc(strlen(s) + 1);
+    if (fromwhere == 6)
+	t = tmp;
+    else if (fromwhere != 4)
+	t = buf = zhalloc(strlen(s) + 1);
     else {
-	buf = s;
+	t = buf = s;
 	s += 2;
     }
-    for (t = buf; *s; s++) {
+    for (; *s; s++) {
 	if (*s == '\\' && s[1]) {
 	    switch (*++s) {
 	    case 'a':
@@ -3303,7 +3307,8 @@
 	} else if (fromwhere == 4 && *s == Snull) {
 	    for (u = t; (*u++ = *s++););
 	    return t + 1;
-	} else if (*s == '^' && (fromwhere == 2 || fromwhere == 5)) {
+	} else if (*s == '^' &&
+		   (fromwhere == 2 || fromwhere == 5 || fromwhere == 6)) {
 	    control = 1;
 	    continue;
 	} else if (*s == Meta)
@@ -3329,6 +3334,10 @@
 	    *t = t[-1] ^ 32;
 	    t[-1] = Meta;
 	    t++;
+	}
+	if (fromwhere == 6 && t != tmp) {
+	    *misc = (int) tmp[0];
+	    return s + 1;
 	}
     }
     DPUTS(fromwhere == 4, "BUG: unterminated $' substitution");
diff -u -r kod/Zsh/arith.yo Doc/Zsh/arith.yo
--- kod/Zsh/arith.yo	Wed Jul  7 09:13:27 1999
+++ Doc/Zsh/arith.yo	Wed Jul  7 09:13:49 1999
@@ -74,11 +74,12 @@
 and XOR operators.
 
 An expression of the form `tt(#\)var(x)' where var(x) is any character
-gives the ascii value of this character and an expression of the form
-`tt(#)var(foo)' gives the ascii value of the first character of the value
-of the parameter var(foo).  Note that this is different from the expression
-`tt($#)var(foo)', a standard parameter substitution which gives the length
-of the parameter var(foo).
+sequence such as `tt(a)', `tt(^A)', or `tt(\M-\C-x)' gives the ascii
+value of this character and an expression of the form `tt(#)var(foo)'
+gives the ascii value of the first character of the value of the
+parameter var(foo).  Note that this is different from the expression
+`tt($#)var(foo)', a standard parameter substitution which gives the
+length of the parameter var(foo).
 
 Named parameters and subscripted arrays can be referenced by name within an
 arithmetic expression without using the parameter expansion syntax.  For

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: PATCH: Enhancing math expressions a bit

[Andrej Borsenkow]

>
> Is your machine fast enough? If so you can try this one. Just start it
> and it will attempt completion after every character you type, showing
> the list of matches. There are even some configuration keys, although
> it should work with compctl, too.
>

Incredible. This is one more thing I was tempted to ask for ... but I always
thought it was impossible :-)

Small problem - after I type the second character, new list is not redisplayed
(no list is actually displayed):

(this is after 'ls Meta-x incremental-complete-word'
bor@itsrm2:~/test/i-c-w%> ls
incremental completion...
abc   acd

now I press ``a'':

bor@itsrm2:~/test/i-c-w%> ls a<=Cursor here
incremental completion...

If I press TAB I get correct list. If I now press the next character I get

bor@itsrm2:~/test/i-c-w%> ls ab
incremental completion...
abc

list is displayed again.

Completion settings:

compconf correct_accept='2n'
compconf match_original='yes'
compconf completer='_complete:_match'
compconf dumpfile='/home/bor/.zcompdump'
compconf path_cursor='yes'
compconf match_insert='unambig'
compconf correct_prompt='correct to:'

/andrej

RE: PATCH: Enhancing math expressions a bit

[Andrej Borsenkow]

>
> I was finally tired of using tests like [[ '#key' -eq 8 ]], so this
> changes getkeystring() so that it can also parse only one character
> (btw, maybe we should turn the `fromwhere' argument into a flags
> argument and add some constants some day). The it makes math mode use
> this function to get the ASCII-value of a character. I.e. you can now
> say [[ '#key' -eq '#\\C-h' ]] and things like that.
>
> I'm not sure if this is the way to go

It surely is useful, but I'd still like to have widgets instead of (even
symbolical) raw bytes ...

Looking at how e.g. incremental search is implemented - it looks, like it simply
calls the same getkeycmd() as main zleread() and some friends. How hard would it
be to provide a builtin, let's say zgetkeycmd (may be, flag to read would do)
with something like

zgetkeycmd widget keys

that simply sets parameter `widget'' to widget name and parameter ``keys'' to
input string? Looks like just a wrapper around getkeycmd() (or am I wrong?)

Combined with suggested keymap switching, this would provide almost unlimited
possibilities.

/andrej

Re: PATCH: Enhancing math expressions a bit

[Peter Stephenson]

Sven Wischnowsky wrote:
> Ok, with the last patch and the one below, I hacked these two widgets
> (they are probably a bit silly). I was tempted to put them into files
> in a directory `Widgets' and stick something like `#widdef' or
> `#zledef' in front, as if we were able to auto-autoload such things. I 
> would really like to generalise the completion-auot-loading code some
> day...

I'll make a directory Functions/Zle and put these in, with appropriate
changes to the functions installation list.  The autoloading will have to
wait.  With all the fiddling around with new directories, I won't bother
posting this unless anybody thinks they need it before the next version
(expected to be probably 3.1.6-test-1 to go back to Richard's convention
with test releases).

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: PATCH: Enhancing math expressions a bit

[Peter Stephenson]

Peter Stephenson wrote:
> Sven Wischnowsky wrote:
> > Ok, with the last patch and the one below, I hacked these two widgets
> 
> I'll make a directory Functions/Zle and put these in

I changed them a bit to make them presentable, so here's what I actually
put in Functions/Zle.  I hope I've deciphered the behaviour OK --- does the
incremental_completer really work yet?

Comments on behaviour:

- <TAB> in i-c-w should probably cause the function to exit if it
  gets a unique completion.  (Note menucompletion is now explicitly
  turned off inside the function.)
- a left parenthesis typed in insert-files is causing the whole function to
  crash; probably also nobadpattern needs to be set inside (I have it
  set all the time).


# incremental-complete-word() {

# Autoload this function, run `zle -N <func-name>' and bind <func-name>
# to a key.

# This allows incremental completion of a word.  After starting this
# command, a list of completion choices is shown after every character you
# type, which you can delete with ^h or DEL.  RET will accept the
# completion so far.  You can hit TAB to do normal completion and ^g to
# abort back to the state when you started.
#
# Completion keys:
#   incremental_prompt   Prompt to show in status line during icompletion
#   incremental_stop     Pattern matching keys which will cause icompletion
#                        to stop and the key to re-executed
#   incremental_break    Pattern matching keys which will cause icompletion
#                        to stop and the key to be discarded
#   incremental_completer  Name of completion widget to call to get choices

emulate -L zsh
unsetopt menucomplete # doesn't work well

local key lbuf="$LBUFFER" rbuf="$RBUFFER" pmpt

[[ -n "$compconfig[incremental_completer]" ]] &&
set ${(s.:.)compconfig[incremental_completer]}
pmpt="${compconfig[incremental_prompt]-incremental completion...}"

zle list-choices
zle -R "$pmpt"
read -k key

while [[ '#key' -ne '#\\r' && '#key' -ne '#\\n' &&
         '#key' -ne '#\\C-g' ]]; do
  if [[ "$key" = ${~compconfig[incremental_stop]} ]]; then
    zle -U "$key"
    return
  elif [[ "$key" = ${~compconfig[incremental_break]} ]]; then
    return
  elif [[ '#key' -eq '#\\C-h' || '#key' -eq '#\\C-?' ]]; then
    [[ $#LBUFFER -gt $#l ]] && LBUFFER="$LBUFFER[1,-2]"
  elif [[ '#key' -eq '#\\t' ]]; then
    zle complete-word "$@"
  else
    LBUFFER="$LBUFFER$key"
  fi
  zle list-choices "$@"
  zle -R "$pmpt"
  read -k key
done

if [[ '#key' -eq '#\\C-g' ]]; then
  LBUFFER="$lbuf"
  RBUFFER="$rbuf"
fi
zle -Rc
# }


# insert-files() {

# Autoload this function, run `zle -N <func-name>' and bind <func-name>
# to a key.

# This function allows you type a file pattern, and see the results of the
# expansion at each step.  When you hit return, they will be inserted into
# the command line.

local key str files

files=( *(N) )
if (( $#files )); then
  zle -R "files: ${str}_" "$files[@]"
else
  zle -R "files: ${str}_ (failed)"
fi
read -k key
while [[ '#key' -ne '#\\r' && '#key' -ne '#\\n' &&
         '#key' -ne '#\\C-g' ]]; do
  if [[ '#key' -eq '#\\C-h' || '#key' -eq '#\\C-?' ]]; then
    [[ -n "$str" ]] && str="$str[1,-2]"
  else
    str="$str$key"
  fi
  files=( ${~str}*(N) )
  if (( $#files )); then
    zle -R "files: ${str}_" "$files[@]"
  else
    zle -R "files: ${str}_ (failed)"
  fi
  read -k key
done
zle -Rc
if [[ '#key' -ne '#\\C-g' && $#files -gt 0 ]]; then
  [[ "$LBUFFER[-1]" = ' ' ]] || files=('' "$files[@]")
  LBUFFER="$LBUFFER$files "
fi
# }

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: PATCH: Enhancing math expressions a bit

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > This does that: it replaces `keys' with `KEYS' and that contains the
> > literal character codes.
> 
> Well, here's some documentation.

Ouch, sorry.

> But I'm worried about what happens with
> control-space.  Might it not be better to use an array with the literal
> codes in (so a null-string means ^@), or alternatively provide a length
> parameter, or use some form of metafication?

(Now I finally understood why you mentioned that lately...)

Urgh, yes, this is ugly (at least $(( #keys )) correctly returns zero
in this case). I wouldn't be against going back to some kind of readable
form, but I would really like to have it report keys in the same way
as `read'. Maybe it would be better to leave `keys' alone and add an
option to `read' that says that keys are to be reported as arrays of
bindkey-like strings? (Hm, -K is unused.)
The solution with a separate number-of-keys parameter looks a bit odd,
doesn't it?

> > Now, should we add a way to turn such codes into a readable form?
> 
> Can probably be done quite simply with a shell function, which could be
> marked #autoload if needed.

Yes.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Enhancing math expressions a bit

[Peter Stephenson]

> > But I'm worried about what happens with
> > control-space.
> 
> Urgh, yes, this is ugly (at least $(( #keys )) correctly returns zero
> in this case).

That's probably enough for most purposes, particularly if we write a
function to use it.  Internal handling of nulls is consistent enough that
things ought to work.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: PATCH: Enhancing math expressions a bit

[Sven Wischnowsky]

I wrote:

> If we once agree to use this patch, we should probably change
> the `keys' special parameter to a special scalar with just the literal 
> characters.

This does that: it replaces `keys' with `KEYS' and that contains the
literal character codes.

I hope you agree that it's better to have this consistent with `read'.

Now, should we add a way to turn such codes into a readable form?

Bye
 Sven

P.S.: I should have sent this before test-1.


diff -u os/Zle/zle_params.c Src/Zle/zle_params.c
--- os/Zle/zle_params.c	Tue Jul 13 10:59:34 1999
+++ Src/Zle/zle_params.c	Tue Jul 13 14:52:46 1999
@@ -67,7 +67,7 @@
         zleunsetfn, NULL },
     { "LASTWIDGET", PM_SCALAR | PM_READONLY, NULL, FN(get_lwidget),
         zleunsetfn, NULL },
-    { "keys", PM_ARRAY | PM_READONLY, NULL, FN(get_keys),
+    { "KEYS", PM_SCALAR | PM_READONLY, NULL, FN(get_keys),
         zleunsetfn, NULL },
     { "NUMERIC", PM_INTEGER | PM_UNSET, FN(set_numeric), FN(get_numeric),
         unset_numeric, NULL },
@@ -247,29 +247,10 @@
 }
 
 /**/
-static char **
+static char *
 get_keys(Param pm)
 {
-    char **r, **q, *p, *k, c;
-
-    r = (char **) zhalloc((strlen(keybuf) + 1) * sizeof(char *));
-    for (q = r, p = keybuf; (c = *p); q++, p++) {
-	k = *q = (char *) zhalloc(5);
-	if (c & 0x80) {
-	    *k++ = 'M';
-	    *k++ = '-';
-	    c &= 0x7f;
-	}
-	if (c < 32 || c == 0x7f) {
-	    *k++ = '^';
-	    c ^= 64;
-	}
-	*k++ = c;
-	*k = '\0';
-    }
-    *q = NULL;
-
-    return r;
+    return keybuf;
 }
 
 /**/

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Enhancing math expressions a bit

[Peter Stephenson]

Sven Wischnowsky wrote:
> This does that: it replaces `keys' with `KEYS' and that contains the
> literal character codes.

Well, here's some documentation.  But I'm worried about what happens with
control-space.  Might it not be better to use an array with the literal
codes in (so a null-string means ^@), or alternatively provide a length
parameter, or use some form of metafication?

> Now, should we add a way to turn such codes into a readable form?

Can probably be done quite simply with a shell function, which could be
marked #autoload if needed.

--- Doc/Zsh/zle.yo.ky2	Wed Jun 23 15:47:06 1999
+++ Doc/Zsh/zle.yo	Tue Jul 13 14:36:22 1999
@@ -154,12 +154,9 @@
 item(tt(LASTWIDGET) (scalar))(
 The name of the last widget that was executed.
 )
-vindex(keys)
-item(tt(keys) (array))(
-The keys typed to invoke this widget, one element per
-key. Control-keys are reported with a leading `tt(^)', as in `tt(^A)',
-and meta-keys are reported with a leading `tt(M-)', as in `tt(M-a)' and 
-`tt(M-^A)'.
+vindex(KEYS)
+item(tt(KEYS) (scalar))(
+The keys typed to invoke this widget, as a literal string.
 )
 vindex(NUMERIC)
 item(tt(NUMERIC) (integer))(

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: PATCH: Enhancing math expressions a bit

[Sven Wischnowsky]

Peter Stephenson wrote:

> I changed them a bit to make them presentable, so here's what I actually
> put in Functions/Zle.  I hope I've deciphered the behaviour OK --- does the
> incremental_completer really work yet?

I had planned to add some comments when they are stored in files
anyway.
The incremental completer does work for me and the completion
configuration I have. Due to Andrej's comment I also tried it with
`zsh -f' and the new completion system and there it worked,
too. However, I haven't tested everything (of course) and did only
very cursory testing without the new completion system. Also there may 
be other things we might want to make configurable... (this started as 
a play, after all).

Btw. if we once make auto-autoloading generic, we probably want to do
the same for configuration? With online-documentation a la run-help?
With registration of configuration keys (so that we can complete them)?

> Comments on behaviour:
> 
> - <TAB> in i-c-w should probably cause the function to exit if it
>   gets a unique completion.  (Note menucompletion is now explicitly
>   turned off inside the function.)

Yes, maybe. We'll then need a way to find that out, though. And we
probably should make it user-configurable since now you can just
happily go on typing multiple words and from time to time hit TAB when 
the list says that it may be interesting. This also suggests another
enhancement: let it play together with the new completion system so
that that gives i-c-w information about the unambiguous string. i-c-w
could then display that in the prompt or something (and draw attention 
toward it if there is something the code could insert automatically).

> - a left parenthesis typed in insert-files is causing the whole function to
>   crash; probably also nobadpattern needs to be set inside (I have it
>   set all the time).

Yes, I used this only to test the list-display-stuff. I've no idea if
and when this may be interesting to have.

> #   incremental_completer  Name of completion widget to call to get choices

Nay, it's the list of completers to give to _main_complete.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Enhancing math expressions a bit

[Peter Stephenson]

Sven Wischnowsky wrote:
> > #   incremental_completer  Name of completion widget to call to get choices
> 
> Nay, it's the list of completers to give to _main_complete.

Aha, this is what I meant by asking `does incremental_completer really
work'.  I'd forgotten it got passed down the function widget and was
thinking the zle call was using it to decide what function to call.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

RE: PATCH: Enhancing math expressions a bit

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > Is your machine fast enough? If so you can try this one. Just start it
> > and it will attempt completion after every character you type, showing
> > the list of matches. There are even some configuration keys, although
> > it should work with compctl, too.
> >
> 
> Incredible. This is one more thing I was tempted to ask for ... but I always
> thought it was impossible :-)
> 
> Small problem - after I type the second character, new list is not redisplayed
> (no list is actually displayed):
> 
> (this is after 'ls Meta-x incremental-complete-word'

Ah, I didn't try execute-named-command. zrefresh() should still print
a *new* list even if clearlist is set.

This should probably be applied to 3.0.6, too. I don't know if we have 
a possibility to trigger this in that version, though.

Bye
 Sven

diff -u os/Zle/zle_refresh.c Src/Zle/zle_refresh.c
--- os/Zle/zle_refresh.c	Wed Jul  7 11:28:50 1999
+++ Src/Zle/zle_refresh.c	Wed Jul  7 13:02:01 1999
@@ -281,7 +281,9 @@
 	    clearflag = 0;
 	    resetneeded = 1;
 	}
-	listshown = showinglist = 0;
+	listshown = 0;
+	if (showinglist != -2)
+	    showinglist = 0;
     }
     clearlist = 0;
 

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Enhancing math expressions a bit

[Sven Wischnowsky]

Helmut just told me that there is a typo in that patch (6995). Sorry,
forgot to diff it again after trying/fixing.


Bye
 Sven

--- os/math.c	Wed Jul  7 11:28:43 1999
+++ Src/math.c	Wed Jul  7 11:29:47 1999
@@ -361,7 +361,7 @@
 
 		    ptr++;
 		    ptr = getkeystring(ptr, NULL, 6, &v);
-		    uuval = v;
+		    yyval = v;
 		    unary = 0;
 		    return NUM;
 		}

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de