From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24940: [PATCH] Add should-call, should-not-call, and their tests Date: Tue, 15 Nov 2016 17:24:21 +0200 Message-ID: <83mvh0hil6.fsf@gnu.org> References: <8337iuhxgu.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1479223529 31379 195.159.176.226 (15 Nov 2016 15:25:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 15 Nov 2016 15:25:29 +0000 (UTC) Cc: 24940@debbugs.gnu.org To: Gemini Lasswell Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 15 16:25:21 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1c6fbf-0005dH-FA for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Nov 2016 16:25:07 +0100 Original-Received: from localhost ([::1]:47013 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6fbi-00066o-M6 for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Nov 2016 10:25:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44657) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6fbb-00065t-8P for bug-gnu-emacs@gnu.org; Tue, 15 Nov 2016 10:25:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6fba-0002Qv-74 for bug-gnu-emacs@gnu.org; Tue, 15 Nov 2016 10:25:03 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42949) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c6fba-0002Qi-3O for bug-gnu-emacs@gnu.org; Tue, 15 Nov 2016 10:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c6fbZ-0008Jc-Tb for bug-gnu-emacs@gnu.org; Tue, 15 Nov 2016 10:25:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Nov 2016 15:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24940 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 24940-submit@debbugs.gnu.org id=B24940.147922345431904 (code B ref 24940); Tue, 15 Nov 2016 15:25:01 +0000 Original-Received: (at 24940) by debbugs.gnu.org; 15 Nov 2016 15:24:14 +0000 Original-Received: from localhost ([127.0.0.1]:58348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6fao-0008IW-9I for submit@debbugs.gnu.org; Tue, 15 Nov 2016 10:24:14 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:53423) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6fan-0008IL-14 for 24940@debbugs.gnu.org; Tue, 15 Nov 2016 10:24:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6fah-0001zy-0U for 24940@debbugs.gnu.org; Tue, 15 Nov 2016 10:24:07 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6fag-0001zo-TQ; Tue, 15 Nov 2016 10:24:06 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3045 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c6fag-0005UE-87; Tue, 15 Nov 2016 10:24:06 -0500 In-reply-to: (message from Gemini Lasswell on Mon, 14 Nov 2016 21:52:23 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:125714 Archived-At: > From: Gemini Lasswell > Cc: 24940@debbugs.gnu.org > Date: Mon, 14 Nov 2016 21:52:23 -0800 > > I'll modify the tests I've written to focus on "the behavior". Thank you. > > might do the latter. A better way, though perhaps much harder, would > > be to test something much more basic that is common to _any_ prompt, > > like look in the echo-area or the minibuffer buffers for suitable > > text, or maybe even C-level infrastructure that catches the situation > > where Emacs waits for user input. > > I agree that infrastructure to allow a test to set up input to be > supplied to the next prompt and to read the prompt message would be a > better solution. You are talking about mocking user input, whereas I was talking about a feature that could tell whether Emacs asked for user input in any way, even if the user herself provided that input. Of course, mocking input is also an important part of a test suite. > The remaining problem that I see is that lots of code in lots of places > suppresses messages depending on called-interactively-p, > executing-kbd-macro and/or noninteractive, and although that doesn't > just affect tests that use keyboard macros, it does make it hard to test > how Emacs behaves interactively. We could have a separate knob for that, to be used by the test suite. > > If we can agree that the above use cases are the only ones where such > > macros should be used, then these macros should be much leaner than > > what you propose, because there should be no need to provide many of > > the features in your proposal, like testing the arguments and the > > return value, or the number of times the subroutines are called. > > The leanest version I can think of would be: > > (with-added-advice BINDINGS > BODY) > > where BINDINGS is a list of argument lists for advice-add. It would call > advice-add once for each element of BINDINGS, execute BODY, and then > remove all the added advice. No, I meant a macro that would return non-nil if some FUNCTION was called during execution of that macro's body.