bug#52380: 28.0.50; [PATCH] run-python no longer focuses interpreter

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Makes sense to me; pushed to emacs-28.
>
> But then I reverted it, because it led to a test failure, so could you
> have a look at that?

Based on my understanding of

- my digression on buffers and windows in my subthread on ERT,

- how buffer "currentness" relates to window "selectedness" in the
  context of a regular command loop vs during a test execution,

- what Tino attempted to fix with bug#31398,

… my inclination would be to (1) keep my patch as-is, (2) amend the test
to check (selected-window) rather than (current-buffer), and (3) add a
comment to explain what we want to test and why we do it that way[1].

We could keep the call to (set-buffer) in run-python, but AFAICT it's
redundant for user interaction: pop-to-buffer selects the window, so
when the command loop returns to the user the *Python* buffer will be
made current anyway.

Does this sound… sound?  If so, I'll submit a v2 amending
python-tests--bug31398.


[1] And optionally (4) start a thread on emacs-devel to better
    understand ERT pitfalls.  I seem to keep stumbling on them; I dimly
    remember struggling to write Elisp code that would reproduce a
    tricky issue with undo and electric-pair-mode (that was 100%
    reproducible interactively), and struggling to write font-lock tests
    because some fontification passes are not triggered unless something
    happens interactively.

    (Or something.  I'll do my research before starting this thread,
    obviously)

    I think at the very least, some documentation of these issues in the
    ERT manual would help; ideally ERT could also provide helpers to
    simulate a "regular command loop".