From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel Subject: Re: Some testing issues Date: Sat, 08 Jul 2017 16:51:28 +0200 Message-ID: <87y3rznfrj.fsf@rosalinde> References: <8737a8j61r.fsf@rosalinde> <59608730.3050308@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1499525515 7661 195.159.176.226 (8 Jul 2017 14:51:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 8 Jul 2017 14:51:55 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 08 16:51:52 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dTr5H-0001YG-Hl for ged-emacs-devel@m.gmane.org; Sat, 08 Jul 2017 16:51:47 +0200 Original-Received: from localhost ([::1]:33117 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTr5M-0002rw-Tm for ged-emacs-devel@m.gmane.org; Sat, 08 Jul 2017 10:51:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTr56-0002on-JY for emacs-devel@gnu.org; Sat, 08 Jul 2017 10:51:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dTr53-0002Mz-D3 for emacs-devel@gnu.org; Sat, 08 Jul 2017 10:51:36 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:58508) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dTr53-0002MW-1K for emacs-devel@gnu.org; Sat, 08 Jul 2017 10:51:33 -0400 Original-Received: from rosalinde ([83.135.5.146]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MQeET-1d6wL13vuH-00U3zZ; Sat, 08 Jul 2017 16:51:31 +0200 In-Reply-To: <59608730.3050308@gmx.at> (martin rudalics's message of "Sat, 08 Jul 2017 09:18:08 +0200") X-Provags-ID: V03:K0:N4QFK9/xkTCsDT+mMyp6Rgwakweoh+h5IAQ2xJQhfmHp6QYCcWp TpYaU2IouYDescQmw0zcVwEssFcE7WjssJMQSETS8jiq7BnAzUqwi7Okyug0fluh59eVPQu O8sIRMINZIDP7hzuNyBUEmELWtg+qGlMMz9JmXWnedzRoUg5Hhk9YKboytV6mbQ8cBFO3Zc MePUDZO77oVtccI2tXZ6A== X-UI-Out-Filterresults: notjunk:1;V01:K0:og0pqz3IPUY=:TBpic34nJElxsacSMDTX6g NNz/3rTYwC74Oxm8XESyOT3cWaMb9teKsKIv7oC31ac6/C0C4aNBR9dHYh//uW0819DiJG7XP X4Jo46UTpwW/XkALAzFgxAjrjOFmSP8NW8H1uLwkNo33aOOxtoOna8+APqjPYFivb1vaeVSaE ffZQAfkSsnf2cOA0P1tQOFpoxZYoQWwBriwBGzZjCp1JJU+hLYXXT6hgb4xtQUZ/3etkuv52I WhXk3ZnCTsbNOxJW4UiLV3KfBFnVPz+MFs/Dx79ysvDeVOl0PgN7+6UdB4MBn05wESwYcywEM 0wx+/8QKSih5ify+vyJ6tqPDaZiKtymTgIHuCYa1GD0zXMP7EcPv5q2DaeiAqSpO7qHekMqz7 3qrbtW57gNMd3VLR0kIUbO5rB5PUo2GWMNtS2nABJCfY/x6/gjmvooIaGDzn7BDcCfvHRvdtZ 0nrGlaRxCbsTOiaymqLlJteZ9DABvr3OeEsBJDhtjtd4scgQfy2VQyOmTUeLVqJb3SbfI2nXn 5NjcR1AQqgkshJftViCsejSHDa4iZxn6ARVuIxbOICPjtW7reRFSPArNmsjuHMN4D/PdLmjNO 4Ev10/tP4NlFSSKq/gJKVlqM/9hymUHD2IvA+7WHokOjqTezS8TqvNU1hWJ+/c8yoSvGSrYVq wBySSjlskzvrrWClWejtdo1CbvCc8h9293gkD6lnTRsVcZp5zT21tGceepNBBSlqIrfdJXBc2 lLIFHnd0ZAkdo7U1R2Iv0jx4H4e0wGf/+u6Wipt0XNgUDoo9WI0JqjYbugVLhtDOSOK00M4O X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.17.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:216327 Archived-At: On Sat, 08 Jul 2017 09:18:08 +0200 martin rudalics wrote: >> And lastly, in one case, the test succeeds >> without the set-window-buffer call when run interactively, but fails >> without it when run in batch mode from the shell. Any idea what's going >> on here? (If anyone wants to take a closer look, comments in the test >> file point out the problematic cases.) > > The interactive call might succeed because command_loop_1 makes the > selected window's buffer current in > > set_buffer_internal (XBUFFER (XWINDOW (selected_window)->contents)); > > Supposedly, testing =E2=80=98recenter=E2=80=99 doesn't make much sense wi= thout a frame. True, though when I step through the code in the interactive test, the condition (pos-visible-in-window-p shown) is true, so recenter is not called; so the question to me is why this is not the case in the batch run. >> A second problem concerns trying to reference a message in a test. The >> function todo-toggle-view-done-items outputs a message if the category >> contains no done items, and the test captures this by calling >> current-message immediately after todo-toggle-view-done-items. This >> works when running the test interactively, but in a batch run, >> current-message is nil (though the message is output in the shell). >> Why? (I avoid the failure in batch mode by testing a different but >> effectively equivalent condition.) > > =E2=80=98current-message=E2=80=99 returns "the string currently displayed= in the echo > area" and there's no echo area in batch mode. Yes, as Noam also pointed out; I didn't think carefully enough about the use of current-message. >> Finally, one of the tests involves a display overlay that hides the item >> header, which as a consequence, when using todo-mode, prevented the >> cursor from appearing where the code put point, resulting in a display >> bug. I fixed this (in master 264dd81) by moving point to the first >> visible position after the overlay. But when running the test, the >> overlay evidently does not inhibit point, but since the test, following >> the bugfix code in todo-mode.el, assumes it does, it fails. It seems >> that the test environment does not reflect the same display mechanisms >> that using the code does. I haven't found a solution or workaround for >> this, so the test is currently marked ":expected-result :failed". I >> hope someone can come up with a better alternative. > > You need a frame to display something and there's none in batch mode. > Hence you can't test display features in batch mode. Thanks for clarifying that for me. I guess I'll have to leave such features untested, or is there an alternative? Thanks for the feedback. Steve Berman