From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5730 invoked from network); 23 Nov 1999 11:31:55 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 Nov 1999 11:31:55 -0000 Received: (qmail 1534 invoked by alias); 23 Nov 1999 11:31:38 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8748 Received: (qmail 1527 invoked from network); 23 Nov 1999 11:31:38 -0000 Date: Tue, 23 Nov 1999 12:31:30 +0100 (MET) Message-Id: <199911231131.MAA08006@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Tanaka Akira's message of 22 Nov 1999 22:56:41 +0900 Subject: Re: Completion test suite Tanaka Akira wrote: > In article <199911220934.KAA04967@beta.informatik.hu-berlin.de>, > Sven Wischnowsky writes: > > > Because it *is* quite complicated, so much so that I can't tests > > everything. > > So, definitely we need some automatic test suite for completion > system. > > When I tried it with expect, I found that it is very difficult because > expect's support of screen based user interfaces like zsh (and > other termcap/terminfo based program and curses based program) is not > so good. > > I think that zsh should have some noninteractive way to use completion > system for this purpose. If we can invoke completion system > noninteractively with an arbitrary command line and zsh can dumps > its completion result, it is enough to write test suite, maybe. I don't think so. First, this would leave the problem unsolved that we have to find out that the results or ok. I.e. either some pour sould would have to go through the output and look if it's correct or everyone who writes a completion function would have to extend the test script so that it can check it automatically. Considering the amount that would have to be tested (and all the dependencies on the environment: files that have to existent, different settings for styles, different _sort_tags functions, commands that have to be existent in some version or not, compmatchers,...) noone will volunteer for the first possibility. And since most people are even to lazy to write descriptions I'm sure that most people would be to lazy to add test-code. And that would have to be correct under all circumstances, too. Sounds completely impossible to me. The other problem is that the completion code relies in some places on zle being active. In some cases it is even visible: the special zle parameters that are used by some completion functions. In other cases it is hidden, but, for example, the listing is really done by zle (complete supplies the function but that is invoked by zle). Or think about the auto_menu stuff, where we rely on zle to set some variables. Etc, etc... In short: I don't think I would even try to write that, but I would be willing to give the implementor every help I can, of course. Bye Sven P.S.: Yes, sure, we could at least try to test some of the things completion does: is the correct string inserted and are the correct matches being generated. But that would still leave us with the problems of the first form. -- Sven Wischnowsky wischnow@informatik.hu-berlin.de