From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: burden of maintainance Date: Fri, 02 Oct 2015 21:16:58 +0200 Message-ID: <87y4flrsgl.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> <837fn55ds7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1443815117 31668 80.91.229.3 (2 Oct 2015 19:45:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 Oct 2015 19:45:17 +0000 (UTC) Cc: andreas.roehler@online.de, esperanto@cumego.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 02 21:45:08 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 1Zi6GR-0007ie-D2 for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2015 21:45:07 +0200 Original-Received: from localhost ([::1]:34799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi6GQ-0001wI-Sf for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2015 15:45:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37443) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi5pK-0002hu-O8 for emacs-devel@gnu.org; Fri, 02 Oct 2015 15:17:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zi5pH-0003qr-I7 for emacs-devel@gnu.org; Fri, 02 Oct 2015 15:17:06 -0400 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:33321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi5pH-0003qM-DM for emacs-devel@gnu.org; Fri, 02 Oct 2015 15:17:03 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6311A20B8F for ; Fri, 2 Oct 2015 15:17:01 -0400 (EDT) Original-Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 02 Oct 2015 15:17:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=JI5zhLxrDdQOyYBtOKSpJ43/cX0=; b=eLC6J bHHM2z73wRFsrvPp8U4YsArgpycBiKita+vy+8Ca4TCag2B6K3UpGvMcUBdiqXtP CQwJfVNtwiIfXnbYwv3q4G1r5FJT6BvbpaQ3Y88+1WkhW698fYulLf7mxj7Y+FZ4 ISLzE4u5P+fJIpCO4KHw5I2REXbH1klHryMeeo= X-Sasl-enc: bWwERkBBD/XydnO20c5NxTbjwH/j5zVp5Cp5uiWbfYNu 1443813420 Original-Received: from thinkpad-t440p (unknown [2.161.209.103]) by mail.messagingengine.com (Postfix) with ESMTPA id 7AC05680120; Fri, 2 Oct 2015 15:17:00 -0400 (EDT) Mail-Followup-To: Eli Zaretskii , esperanto@cumego.com, andreas.roehler@online.de, emacs-devel@gnu.org In-Reply-To: <837fn55ds7.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 02 Oct 2015 21:24:56 +0300") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) 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: 66.111.4.28 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:190740 Archived-At: Eli Zaretskii writes: >> > We are mis-communicating again: I meant features which display >> > something or involve interactive keyboard input. >> >> 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? No, if something is actually displayed correctly cannot be tested like so. What I had in mind were things like testing if fontification works properly by checking if the 'face property is set to some expected face when point is one some keyword. > 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. That's obviously not what I've head in mind. But I don't think that's an area where we need a special focus on tests. At least I have the feeling that there are only few bugs wrt. the display engine. >> 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. Yes, eventually. But it would at least be a first step. And this hypothetical recorder could also be exposed to the user for creating replayable recipes for bugs they report. Where a tester would add assertions, the user would just write what he's expecting, and whoever fixes the bug could easily turn the string into assertions, and voila, there's the regression test for the bug. Bye, Tassilo