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

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

>  >>   > *Completions* is not a modal window.
>  >>
>  >> I don't mind to disagree here.
>  >
>  > Not sure it is important to discuss this, but what is your
>  > disagreement?
> 
> I consider the window showing *Completions* modal.

That's clear.  But what is your reason (evidence) for saying
that.

>  >> The modal activity in the case at hand is picking up a completion.
>  >
>  > That's not modal, if by that you mean that you cannot (or even
>  > that you should not) do anything else until you choose a
>  > completion candidate.  You can do all kinds of things while
>  > the minibuffer is waiting for you to choose a candidate.
>  > There is nothing modal about this.
> 
> It is modal.

How so?  In what way?  IOW, why do you think so?

> But since Emacs is always nice to its users it has its own
> interpretation of modality.  It shows modal windows where the user wants
> them and allows the user to do virtually anything while they are shown.

Then in what way are they modal?  It sounds like you have an
original meaning of modal in mind.  What is it?

> There's one restriction: Emacs expects the user to be nice to it as
> well.
> 
> Emacs also has shy windows like the one from Ispell.  These go away when
> the user doesn't pay attention to them.  Modal windows are a bit more
> insistent.  But as I mentioned earlier their only rules are: A modal
> window should disappear immediately when it's no more needed but till
> then it should remain continuously visible.

Ah, so that's what you mean by "modal window".  Not that a user
is prevented from doing something else than interact with it,
but that (a) it remains visible until (b) it is no longer needed,
when it disappears.

That is not the usual meaning of "modal", but OK, good to know.

I imagine that (a) is unnecessary, unless you are suggesting
that a user cannot remove such a window.  I'm guessing that
you perhaps mean, by (a), that no other automatically displayed
window takes its place, and that it is not otherwise removed
automatically.

> And finally we have what you probably would consider modal: Dialogs like
> that of Emacs asking you whether it should save a buffer when exiting.
> There you won't be able to send a bug report until you have either quit
> or given an appropriate answer.
> 
>  > I argue only that (1) the bug-reporting window(s) should be visible
> 
> They usually are except for a few cases involving dedicated windows and
> unsplittable frames.

OK, so only those cases should manifest the bug.

>  > and (2) other windows should not be removed.
>  >
>  > A start might be to combine the instructions/help window with
>  > the reporting window.  The reporting window already has lots
>  > of instructional text in it.  Using a separate page in that
>  > window for the help info would go a long way toward stopping
>  > the reporting window from being occluded.
>  >
>  > It might even help if the order of creation of the two bug
>  > windows were reversed (dunno).  What happens now is that the
>  > more important of the two windows is hidden and the less
>  > important of the two is shown - just the help.  That's not
>  > ideal.
> 
> All this is coded in Elisp.  Why don't you give it a try?

Sorry; I am not trying to fix the bug, myself.  And if I did,
I'm sure that you or someone else would reject the result of
my effort.

I am only trying to help by explaining the bug report, and the
bug as I see it.  HTH.