bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24940: [PATCH] Add should-call, should-not-call, and their tests


From: Eli Zaretskii
Subject: bug#24940: [PATCH] Add should-call, should-not-call, and their tests
Date: Tue, 15 Nov 2016 17:24:21 +0200

> From: Gemini Lasswell <gazally@runbox.com>
> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]