Re: Adding tests for zle? The missing X series tests

[Peter Stephenson <Peter.Stephenson@xxxxxxx>]

On Tue, 20 Dec 2011 08:20:07 -0800
Felix Rosencrantz <f.rosencrantz@xxxxxxxxx> wrote:
> I was thinking about refactoring doisearch(), so it is easier to
> read/understand/change, so the base function might look like below.
> Though before attempting this I would like to have the safety net of
> tests, to assure the changes don't break the incremental search
> widgets. There are no zle tests, though the letter X was reserved for
> zle tests.  I was wondering if anyone had thought about how this might
> be done.  I looked at the tests for the completion, and tried to copy
> that, though got mired down a little, since I'm not  familiar with the
> terminal codes.  The completion code added xml like tags with zstyle
> formatting controls (list-colors, message format, etc) and then parses
> that output, though the incremental search widgets don't have that
> kind of control.

This is definitely at the expensive end of the market... at the level
you're talking about, simply verifying that the right widgets get called
isn't good enough, you need to check what's happening to the command
line.  I don't see any real alternative to checking something coming
out of the shell that is or corresponds to the terminal sequences.

We could probably arrange to rig up our own pseudotermcap entry that
outputs something along the lines that the completion code does, but
this sounds like a lot of work --- we're at least two generations of
terminal library along from termcap, so ensuring every test set-up uses
our substitute terminal definitions, and that we've caught all relevant
codes, seems like hard work.

Probably easier is to intercept the terminal output at a low-level
inside the shell by having an option that directly outputs values from
an associative array with termcap codes as keys (this doesn't need to be
particularly user-friendly, and as zsh internally still uses termcap
codes this looks like the easiest way to test it) instead of using the
termcap output functions.  That shouldn't be too much work --- termcap
is vastly simpler than e.g. curses --- and makes the job no harder (!)
than testing completion.  There are also potential uses for this in
debugging --- it should provide a simpler method of finding out what has
caused the cursor to end up where it did.

Simpler still is just to output some marked up version of the termcap
code itself.  You could have a format string stored in a shell variable
with placeholders to insert the code and a numeric argument within it to
get the markup.  The extra flexibility for an associative array isn't
hard, since all the framework for it is already there, but maybe we
don't need it.

I'm on holiday from tomorrow for two weeks and while I'll be able to
read email I'll be in Androidland so am unlikely to be very
communicative.

-- 
Peter Stephenson <pws@xxxxxxx>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog