Test failures in artih and arguments

Test failures in artih and arguments

[Felix Rosencrantz]

I'm seeing 2 test failures on RedHat 7.2.  Not sure how new these are.

-FR.

./C01arith.ztst: starting.
*** /tmp/zsh.ztst.out.690	Tue Jan 22 10:01:53 2002
--- /tmp/zsh.ztst.tout.690	Tue Jan 22 10:01:53 2002
***************
*** 1 ****
! 31415
--- 1 ----
! 31415.
Test ./C01arith.ztst failed: output differs from expected as shown 
above for:
  float light there
  integer rnd
  (( light = 3.1415 )) &&
  let 'there = light' &&
  print -- $(( rnd = there * 10000 ))
Was testing: basic floating point arithmetic
./C01arith.ztst: test failed.

./Y03arguments.ztst: starting.
*** /tmp/zsh.ztst.out.2530	Tue Jan 22 10:02:28 2002
--- /tmp/zsh.ztst.tout.2530	Tue Jan 22 10:02:28 2002
***************
*** 1,4 ****
! line: {tst -}{}
! MESSAGE:{arg}
! DESCRIPTION:{option}
! NO:{-x}
--- 1 ----
! line: {tst -x }{}
Test ./Y03arguments.ztst failed: output differs from expected as shown 
above for:
 tst_arguments '-x' ':arg:'
 comptest $'tst -\t'
Was testing: argument beginning with minus
./Y03arguments.ztst: test failed.


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

Re: Test failures in artih and arguments

[Peter Stephenson]

Felix Rosencrantz wrote:
> I'm seeing 2 test failures on RedHat 7.2.  Not sure how new these are.
> 
> -FR.
> 
> ./C01arith.ztst: starting.
> *** /tmp/zsh.ztst.out.690	Tue Jan 22 10:01:53 2002
> --- /tmp/zsh.ztst.tout.690	Tue Jan 22 10:01:53 2002
> ***************
> *** 1 ****
> ! 31415
> --- 1 ----
> ! 31415.
> Test ./C01arith.ztst failed: output differs from expected as shown 
> above for:
>   float light there
>   integer rnd
>   (( light = 3.1415 )) &&
>   let 'there = light' &&
>   print -- $(( rnd = there * 10000 ))
> Was testing: basic floating point arithmetic
> ./C01arith.ztst: test failed.

This is when I added the `.' to floating point numbers to discriminate them
from integers when handled as strings, zsh-workers/16423.  The new output
is now correct and the test is wrong.

Index: Test/C01arith.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/C01arith.ztst,v
retrieving revision 1.4
diff -u -r1.4 C01arith.ztst
--- Test/C01arith.ztst	2001/07/09 18:31:25	1.4
+++ Test/C01arith.ztst	2002/01/23 16:14:33
@@ -16,7 +16,7 @@
   print -- $(( rnd = there * 10000 ))
 # save rounding problems by converting to integer
 0:basic floating point arithmetic
->31415
+>31415.
 
   print $(( 0x10 + 0X01 + 2#1010 ))
 0:base input

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Test failures in artih and arguments

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> ...
> 
> ./Y03arguments.ztst: starting.
> *** /tmp/zsh.ztst.out.2530	Tue Jan 22 10:02:28 2002
> --- /tmp/zsh.ztst.tout.2530	Tue Jan 22 10:02:28 2002
> ***************
> *** 1,4 ****
> ! line: {tst -}{}
> ! MESSAGE:{arg}
> ! DESCRIPTION:{option}
> ! NO:{-x}
> --- 1 ----
> ! line: {tst -x }{}
> Test ./Y03arguments.ztst failed: output differs from expected as shown 
> above for:
>  tst_arguments '-x' ':arg:'
>  comptest $'tst -\t'
> Was testing: argument beginning with minus
> ./Y03arguments.ztst: test failed.

Grrrr... that's a result of the fake style patch. Previously, with a
function containing:

  _argument '-x' ':arg:'

doing

  foo -<TAB>

didn't insert anything and displayed be message `arg'.

This was done by some code in _main_complete which I had to change
because otherwise adding completing a faked matched for the `arg'
above wouldn't work. Quite naturally, actually.

If I remember correctly, the behaviour was added on request from
Tanaka Akira.

So we now have the problem that in exactly the same case something we
certainly want to have with faked matches conflicts with the behaviour
we wanted there previously (or even now, without faked matches).

I'm not sure how to solve this.


Bye
  Sven

-- 
Sven Wischnowsky                           wischnow@berkom.de

Re: Test failures in artih and arguments

[Bart Schaefer]

On Jan 25,  9:58am, Sven Wischnowsky wrote:
} 
} Felix Rosencrantz wrote:
} 
} > ***************
} > *** 1,4 ****
} > ! line: {tst -}{}
} > ! MESSAGE:{arg}
} > ! DESCRIPTION:{option}
} > ! NO:{-x}
} > --- 1 ----
} > ! line: {tst -x }{}
} > Test ./Y03arguments.ztst failed: output differs from expected as shown 
} 
} Grrrr... that's a result of the fake style patch. Previously, with a
} function containing:
} 
}   _argument '-x' ':arg:'
} 
} doing
} 
}   foo -<TAB>
} 
} didn't insert anything and displayed be message `arg'.

This isn't quite right -- here's 4.0.4:

schaefer[507] zsh -f
aztec% autoload -U compinit
aztec% compinit -D
aztec% compdef _foo foo
aztec% _foo() { _arguments -x :arg: }
aztec% foo -<TAB>
aztec% foo -x 

The comptest code sets the `format' style for the `completion:*:messages'
and `completion:*:descriptions' contexts.  Only with one of those styles
set is the `x' NOT inserted; without those styles, it's inserted.

It seems to me that the display formatting should not affect what the
possible matches are.  Was this really intended to depend on the `format'
style?

} So we now have the problem that in exactly the same case something we
} certainly want to have with faked matches conflicts with the behaviour
} we wanted there previously (or even now, without faked matches).
} 
} I'm not sure how to solve this.

The problem really is that `-<something>' is a valid match, for any
arbitrary value of <something>, but of course we can only write code to
add or list matches that we know about in advance, not those that can be
fabricated interactively.

So it seems to me that we need a wildcard indicator of some kind, so
that _arguments can add the match `-<wild>'.  This would allow the `-'
to be treated as a prefix of the two matches `-x' and `-<wild>'.  The
list and menu code would then have to special case any match that has
<wild> in it, omitting it from listings but displaying the description
for it (if there is one).

However, I don't have any good suggestions on how to chose <wild> such
that it is guaranteed not to conflict with any possible real match.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Test failures in artih and arguments

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> The problem really is that `-<something>' is a valid match, for any
> arbitrary value of <something>, but of course we can only write code to
> add or list matches that we know about in advance, not those that can be
> fabricated interactively.
> 
> So it seems to me that we need a wildcard indicator of some kind, so
> that _arguments can add the match `-<wild>'.  This would allow the `-'
> to be treated as a prefix of the two matches `-x' and `-<wild>'.  The
> list and menu code would then have to special case any match that has
> <wild> in it, omitting it from listings but displaying the description
> for it (if there is one).
> 
> However, I don't have any good suggestions on how to chose <wild> such
> that it is guaranteed not to conflict with any possible real match.

Good analysis. An dnow I'm back at thinking: do we really want that?

It would mean that in cases like `_argument -longoption :foo:' that
long option names (or, more likely, those long option names) couldn't
be completed. Very ugly, if you ask me.

If we don't want to be able to complete the options, we would just
have to add `$PREFIX' or some such as a possible match.

Sometimes I think that in such cases we should only force the message
to be displayed, even if a match was accepted. And this is also
affected by the fake style thing we are discussing (which might turn a
case of `displaying a message' into `adding some matches').


Bye
  Sven

-- 
Sven Wischnowsky                           wischnow@berkom.de

Re: Test failures in artih and arguments

[Bart Schaefer]

On Jan 30,  9:53am, Sven Wischnowsky wrote:
} 
} Bart Schaefer wrote:
} 
} > So it seems to me that we need a wildcard indicator of some kind, so
} > that _arguments can add the match `-<wild>'.  This would allow the `-'
} > to be treated as a prefix of the two matches `-x' and `-<wild>'.
} 
} Good analysis. And now I'm back at thinking: do we really want that?
} 
} If we don't want to be able to complete the options, we would just
} have to add `$PREFIX' or some such as a possible match.

That would work provided that it was added with the equilvalent of

	compadd -S '' $PREFIX

so that no space would be added after it.
 
} Sometimes I think that in such cases we should only force the message
} to be displayed, even if a match was accepted.

Correct me if I'm wrong, but that would result in something like

zsh% foo -<TAB>
zsh% foo -x 
Completing arg

(assuming "zstyle :completion:* format 'Completing %d'")

That seems a bit confusing.  Or did you mean that, if there was a message
to be forced, then the accepted match would not be completed? That would
be OK, I think.

} And this is also affected by the fake style thing we are discussing
} (which might turn a case of `displaying a message' into `adding some
} matches').

Right, the question becomes how to tell when the message really should
be forced out, and when the faked matches should be used as the possible
completions instead.

Perhaps the thing to do is to treat <wild> as a style context rather than
as a possible match, and determine how to behave based on a style set in
that context.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Test failures in artih and arguments

[Sven Wischnowsky]

Bart Schaefer wrote:

> [ making `foo -<TAB>' with `_arguments -x :arg:' not complete the
>   option ]

Here's a simple patch which seems to work for me. It uses $compstate
to keep the code from inserting matches and also handles faked
matches.

At least it should be good enough as a first implementation.


Bye
  Sven

Index: Completion/Base/Core/_message
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_message,v
retrieving revision 1.4
diff -u -r1.4 _message
--- Completion/Base/Core/_message	25 Feb 2002 09:09:35 -0000	1.4
+++ Completion/Base/Core/_message	25 Feb 2002 09:11:10 -0000
@@ -18,6 +18,8 @@
     ret=0
   done
 
+  (( $compstate[nmatches] )) || compstate[insert]=
+
   return ret
 fi
 
Index: Test/Y03arguments.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/Y03arguments.ztst,v
retrieving revision 1.4
diff -u -r1.4 Y03arguments.ztst
--- Test/Y03arguments.ztst	22 Aug 2001 15:59:27 -0000	1.4
+++ Test/Y03arguments.ztst	25 Feb 2002 09:11:10 -0000
@@ -91,7 +91,7 @@
  comptest $'tst -\t'
 0:argument beginning with minus
 >line: {tst -}{}
->MESSAGE:{arg}
+>DESCRIPTION:{arg}
 >DESCRIPTION:{option}
 >NO:{-x}
 

-- 
Sven Wischnowsky                          wischnow@berkom.de