From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: burden of maintainance Date: Fri, 02 Oct 2015 20:47:50 +0200 Message-ID: References: <560CEA6A.9000907@online.de> <834miaa847.fsf@gnu.org> <560D7F77.8060507@online.de> <83lhbm8kye.fsf@gnu.org> <560E8C80.5040007@cumego.com> <83r3ld5pbh.fsf@gnu.org> <87bnchtcj3.fsf@gnu.org> <837fn55ds7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1443812495 23547 80.91.229.3 (2 Oct 2015 19:01:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 Oct 2015 19:01:35 +0000 (UTC) Cc: esperanto@cumego.com, emacs-devel@gnu.org, andreas.roehler@online.de, Tassilo Horn To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 02 21:01:20 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zi5a0-0004pE-BA for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2015 21:01:16 +0200 Original-Received: from localhost ([::1]:34478 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi5Zu-00034o-MA for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2015 15:01:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi5NW-0007R9-0A for emacs-devel@gnu.org; Fri, 02 Oct 2015 14:48:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zi5NU-00047j-R8 for emacs-devel@gnu.org; Fri, 02 Oct 2015 14:48:21 -0400 Original-Received: from mx1.bahnhof.se ([213.80.101.11]:41794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi5NQ-0003yd-Kb; Fri, 02 Oct 2015 14:48:16 -0400 Original-Received: from localhost (mf.bahnhof.se [213.80.101.20]) by mx1-reinject (Postfix) with ESMTP id 2187040D2E; Fri, 2 Oct 2015 20:48:14 +0200 (CEST) X-Virus-Scanned: by amavisd-new using ClamAV at bahnhof.se (MF4) Original-Received: from mf4.bahnhof.se ([127.0.0.1]) by localhost (mf4.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STDz5EkoQd3n; Fri, 2 Oct 2015 20:48:09 +0200 (CEST) Original-Received: from mta.verona.se (h-235-62.a149.priv.bahnhof.se [85.24.235.62]) by mf4.bahnhof.se (Postfix) with ESMTP id 10E903D785C; Fri, 2 Oct 2015 20:48:08 +0200 (CEST) Original-Received: from localhost (unknown [127.0.0.1]) by mta.verona.se (Postfix) with ESMTP id B200B4EA3C9; Fri, 2 Oct 2015 18:48:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at verona.se Original-Received: from mta.verona.se ([127.0.0.1]) by localhost (exodia.verona.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32aKwg6djGZq; Fri, 2 Oct 2015 20:47:50 +0200 (CEST) Original-Received: from exodia.verona.se (www.verona.se [192.168.200.15]) by mta.verona.se (Postfix) with ESMTP id 330064EA3C7; Fri, 2 Oct 2015 20:47:50 +0200 (CEST) In-Reply-To: <837fn55ds7.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 02 Oct 2015 21:24:56 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 213.80.101.11 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190736 Archived-At: Eli Zaretskii writes: >> From: Tassilo Horn >> Cc: Przemys=C5=82aw Wojnowski , >> andreas.roehler@online.de, emacs-devel@gnu.org >> Date: Fri, 02 Oct 2015 19:18:08 +0200 >>=20 >> Eli Zaretskii writes: >>=20 >> >> Can you give an example? Of course not everything can be tested, but >> >> many things can. >> > >> > We are mis-communicating again: I meant features which display >> > something or involve interactive keyboard input. >>=20 >> Emacs is in a better position here than most other tools because it has >> keyboard macros and can easily inspect the things it displays, e.g., the >> text properties or overlays at point. > > We may be mis-communicating here. Because I cannot see how examining > text properties or overlays can test whether their display on screen > is correct. What am I missing? Can you show an example of what you > had in mind? As a data point, there is an interesting GUI test toolkit called Sikuli, It uses the OpenCV computer vision toolkit to analyze that the display matches expectations. Sikuli is free software if I recall correctly. > > If we are talking about testing the display engine, it should be > possible and relatively easy to provide Lisp access to the "glyph > matrices", which are data structures the display engine builds that > describe what _should_ be on the screen. You can see one specialized > example of that in the function bidi-resolved-levels which I wrote for > testing the bidirectional display. > > But doing the above is only half the way. The other half is the > terminal-specific back-end, either X, w32, NS, or TTY, which actually > converts the glyph matrices to draw commands and delivers the results > to the glass. To test that, we need some way of "sniffing" the > results of this drawing, which requires terminal-specific > infrastructure. > > We then need some "language" to describe the expected results to be > displayed on the screen. For TTY, this is almost trivial, but for > sophisticated GUI display features it's more complicated (think of > fonts, stretches of white space, composed characters, fringe bitmaps, > tool-bar icons, tooltips, etc.). We also need a way of describing the > results of cursor movement. > > When all of these are implemented, then yes, writing display tests > should be relatively easy. But today all this infrastructure doesn't > exist. We don't even have its detailed design. > >> I can think of something like "ERT keyboard-macro tests" where you would >> basically record a keyboard macro and during that, you have some way to >> add some assertions before resuming recording. The whole recorded thing >> could then be stored as an ERT test. > > For testing keyboard input, we need more than that. For example, > consider the simple feature of input history -- you'd need a way to > inject M-p, M-n, etc., and a way of recording the text that is > displayed as result and returned to the caller. > > And please don't forget that keyboard input is only one kind of events > supported by Emacs. There are others, starting with mouse. We'd need > ways to simulate or trigger all of them. > > --=20 Joakim Verona