On Thu, 11 Apr 2019 at 10:05, Eli Zaretskii <eliz@gnu.org> wrote:

> > static intmax_t when_entered_debugger;
> >
> > So I guess we'd need some way of resetting it from Lisp?
>
> Doesn't it work to simply set its value before the second test?

Yes, or in each test, since the tests don't necessarily have knowledge
of what order they're called in (I think it's currently alphabetical
order of test name). See attached diff (against the state of my v3
patch), but it seems a bit silly to make the variable Lisp accessible
just for this obscure test case. I don't see any other way though.

> > As far as I can tell, the normal debugger resets it by calling
> > recursive-edit, but there's no way to return from that without human
> > intervention (I think?).
>
> Doesn't abort-recursive-edit work noninteractively?

Yes, but how can I arrange for it to be called without stopping to
read commands from the user first? E.g., in the following
abort-recursive-edit is too late to do any good:

(progn
  (recursive-edit)
  (abort-recursive-edit))

Using pre-command-hook is also too late, the user has to type
something to trigger the beginning of a certain command first.

(let ((pre-command-hook #'abort-recursive-edit))
  (recursive-edit))

> > +                    ;; On Windows, "nul.FOO" is the empty file for any
> > +                    ;; FOO, in any directory.  So this passes Emacs'
>
> Instead of "is the empty file", I'd say something like "resolves to
> the null device, reading from which sets the EOF condition".

Hmm, while technically more accurate, it seems like a little too much
detail to be useful; I think saying "acts like an always-empty file"
should be enough.