bug#10873: 24.0.93; `report-emacs-bug' obscures bug-reporting buffer (!)

[Drew Adams <drew.adams@oracle.com>]

>  >> This bug is still 100% reproducible in an Emacs 25 build of 2015-12-10:
> 
> There's not much I can do about this.  I can give a simpler recipe with
> emacs -Q: Type C-h f set- RET and see the *Completions* window pop up.
> Then type M-x report-emacs-bug.
> 
> OT1H the window showing the *Completions* buffer is softly dedicated to
> that buffer.  This is necessary to make sure that an intermittent
> ‘display-buffer’ does not steal that window for showing another buffer.
> Windows showing *Completions* should disappear immediately when they are
> no more needed but till then they should be continuously visible.
> 
> OTOH ‘report-emacs-bug’ apparently assumes that it always has two
> windows at its disposal - one for the message and one for help.  This
> assumption misfires with the recipe at hand.  (Note that my machine in
> addition also displays a warning from ‘compose-mail’ which gets usually
> immediately buried when showing either the message or the help.)
> 
> IMO this report is the result of a cockpit error.  As long as a "modal"
> window like that showing *Completions* is open, users should not start
> an unrelated activity, including that of writing a bug report.
> 
> If, however, people think that ‘report-emacs-bug’ should always succeed
> showing both of its windows in every conceivable context, we can do that
> easily by calling ‘delete-other-windows’ before ‘display-buffer’.  This
> will clearly misfire for people showing more than two windows per frame.

Wrt:

> IMO this report is the result of a cockpit error.  As long as a "modal"
> window like that showing *Completions* is open, users should not start
> an unrelated activity, including that of writing a bug report.

The bug report shows a simple recipe; it does not purport to show
a realistic use case.

*Completions* is not a modal window.  And it is not the case that
users cannot or should not start another activity (related or
unrelated) while the minibuffer is active or *Completions* is shown.

Certainly users should not be proscribed from having a completion
in progress while they file a bug report.  Think, for instance, of
`enable-recursive-minibuffers'.  Or think of keys that invoke
commands from the minibuffer - commands that might do nearly
anything.  Or think of wanting to refer to the *Completions*
buffer while filling out a bug report.

The bug-reporting code should not make any special assumptions
about other user activity that might be in progress or done "in
parallel".  It should not assume that either it or some other
activity is modal.  A truly modal activity will in any case do
its best to prevent anything else from interfering.

Certainly preparing a bug report is NOT a modal activity, and
it should not prevent a user from interacting with Emacs in
other ways while the report is being prepared.  Nor should it
assume that the user will not continue to interact with Emacs
in other ways before the report is finished and sent.

Use of the minibuffer should not be proscribed or curtailed just
because bug reporting wants to display some other windows.  And
use of other, non-bug reporting, windows should not be foregone
just because bug reporting wants to display some additional windows.

What should happen is that the bug-reporting windows should both
be visible.  Or at the very least, the most important, not the
least important, of these two windows should be visible.

And as the original bug report said:

  This is a regression starting with Emacs 23.

Since it is a regression it should not be impossible or unfeasible
to obtain the pre-regression behavior again.