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: burden of maintainance Date: Fri, 02 Oct 2015 21:24:56 +0300 Message-ID: <837fn55ds7.fsf@gnu.org> 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> Reply-To: Eli Zaretskii 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 1443811370 5562 80.91.229.3 (2 Oct 2015 18:42:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 Oct 2015 18:42:50 +0000 (UTC) Cc: andreas.roehler@online.de, esperanto@cumego.com, emacs-devel@gnu.org To: Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 02 20:42:38 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 1Zi5Hx-0002Xt-K9 for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2015 20:42:37 +0200 Original-Received: from localhost ([::1]:34405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi5Hx-0004nB-0j for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2015 14:42:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi514-0003nK-JY for emacs-devel@gnu.org; Fri, 02 Oct 2015 14:25:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zi50z-0005T0-LV for emacs-devel@gnu.org; Fri, 02 Oct 2015 14:25:10 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:58423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi50z-0005PG-E5; Fri, 02 Oct 2015 14:25:05 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NVL00D00UT61A00@a-mtaout20.012.net.il>; Fri, 02 Oct 2015 21:25:03 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVL00DPKV5R1X00@a-mtaout20.012.net.il>; Fri, 02 Oct 2015 21:25:03 +0300 (IDT) In-reply-to: <87bnchtcj3.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:190735 Archived-At: > 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? 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 fo= r 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 th= e 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 wa= y 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 event= s supported by Emacs. There are others, starting with mouse. We'd nee= d ways to simulate or trigger all of them.