From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: ert.el --- Emacs Lisp Regression Testing Date: Sat, 05 Jan 2008 15:06:45 +0200 Message-ID: References: <47782302.5000201@fastmail.net> <477F6ADD.4000908@fastmail.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1199538415 14220 80.91.229.12 (5 Jan 2008 13:06:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 13:06:55 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Christian Ohler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 14:07:16 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JB8k3-0005ro-L0 for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 14:07:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB8jh-00020e-3n for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 08:06:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JB8jd-00020D-E3 for emacs-devel@gnu.org; Sat, 05 Jan 2008 08:06:45 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JB8jc-0001zs-W4 for emacs-devel@gnu.org; Sat, 05 Jan 2008 08:06:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB8jc-0001zk-MO for emacs-devel@gnu.org; Sat, 05 Jan 2008 08:06:44 -0500 Original-Received: from romy.inter.net.il ([213.8.233.24]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JB8jY-0000uo-O7; Sat, 05 Jan 2008 08:06:40 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-71-78.inter.net.il [80.230.71.78]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id JUY15195 (AUTH halo1); Sat, 5 Jan 2008 15:06:21 +0200 (IST) In-reply-to: <477F6ADD.4000908@fastmail.net> (message from Christian Ohler on Sat, 05 Jan 2008 12:32:45 +0100) X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:86147 Archived-At: > Date: Sat, 05 Jan 2008 12:32:45 +0100 > From: Christian Ohler > 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.