zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: Adding tests for zle? The missing X series tests
Date: Wed, 21 Dec 2011 08:48:01 -0800	[thread overview]
Message-ID: <111221084801.ZM13070@torch.brasslantern.com> (raw)
In-Reply-To: <CANGpWcegC1R2ayUs34PKK3o3PFFPEKh5wsTVh8mEX5ERi-Sz0Q@mail.gmail.com>

On Dec 20,  8:20am, Felix Rosencrantz wrote:
}
} 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 have thought a bit about this in the past and I think there may be a
sort of brute-force way to do it.  It wouldn't work for everything, but
it should work for most simple ZLE edits and for incremental search in
particular.

First you'd need to set up a zpty session like the completion tests do.
Make sure to give it adequate dimensions so ZLE scrolling does not kick
in (unless that's what you're testing, I guess).

Next you set PS1 to a recognizable string and clear RPS1 etc.  For some
tests you'd might want a recognizable PS2 as well, but for incremental
search it wouldn't be necessary.

Finally you arrange that clear-screen is bound to a well-known keystroke
(the defaut of ctrl-L is probably fine).

Now you're ready to test.  Start sending keystrokes to the zpty and
read back (and probably discard) the zpty output as you do so.  At
the point where you want to check the result, send clear-screen, which
causes the whole screen to be redrawn (even during incremental search)
including the PS1 prompt.  This repaint should result in pretty much a
linear dump of the editor buffers with few or no cursor movements after
the initial screen clear.

Consequently your next zpty read after the clear-screen can scan for
the PS1 string you set previously, in order to skip over the terminal
control output, and then slurp up everything else that was printed and
compare to what you expected to find.

(A quick check using the script command to capture output indicates that
there is a clear-to-end-of-line emitted at the end of each line of the
output, but that should be relatively easy to ignore when parsing.)

This won't uncover terminal-handling bugs like unexpected line wraps at
the last line/column, but it should be able to verify e.g. the search is
finding the right thing at each incremental step.


      parent reply	other threads:[~2011-12-21 16:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-20 16:20 Felix Rosencrantz
2011-12-21 11:39 ` Peter Stephenson
2012-01-04 17:38   ` Peter Stephenson
2012-01-09  0:20     ` Felix Rosencrantz
2012-01-09 10:02       ` Peter Stephenson
2012-01-11 16:45         ` Felix Rosencrantz
2012-01-29 18:49       ` Peter Stephenson
2011-12-21 16:48 ` Bart Schaefer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=111221084801.ZM13070@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).