Re: ert.el --- Emacs Lisp Regression Testing

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 05 Jan 2008 12:32:45 +0100
> From: Christian Ohler <ohler+emacs@fastmail.net>
> Cc: emacs-devel@gnu.org
> 
> > It occurs to me that M-x term could be used to test for redisplay.
> > The idea is that you run a sub-Emacs, send it commands, and check what
> > it displayed (because what it displayed is now in a buffer).
> 
> Does a significant share of the input/redisplay bugs that occur in a GUI 
> Emacs also occur on the terminal?

To answer this question, one should analyze the ChangeLog entries for
display code and partition the bugfixes according to the display
backend.  FWIW, I don't think this is a good way of using our
resources, since there's no easy way of knowing whether a given change
is a new feature or a bugfix.

More generally, I think each display backend has the same chance of
getting a bug as any other.  I also think that all the backends we
currently support are of equal importance.  If others agree, it means
that we need a way to detect bugs in all of the different display
backends.

> The first step would be to identify a few bug reports involving input 
> and redisplay that should be reproducible under M-x term and should make 
> good candidates for automation.

I think the first step is to design and implement infrastructure that
will allow us to compare actual display with the desired one; using
M-x term is just a partial hack that could work in some cases.

For a general-purpose display testing, we need to add code to the
display engine (both its high-level device-independent part, and
lower-level display backend) that would expose to a Lisp application
the glyphs that are produced by the display engine and the
backend-dependent display commands sent to the display API
(termcap/terminfo for text terminal, X for X Window system, etc.).

The lower-level part of the above is more important than the
high-level, because it's eventually the lower-level that is sent to
the underlying display system.  But having the high-level part is also
important, because we sometimes change the translation between
high-level glyphs and the corresponding low-level commands, with the
intent that the displayed stuff remains the same.

In other words, we need a description language for describing the
stuff Emacs is about to display, code in the display engine that will
produce such a description as part of redisplay, and a Lisp interface
to that description.