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

[Drew Adams]

>  >> I consider the window showing *Completions* modal.
>  >
>  > That's clear.  But what is your reason (evidence) for saying
>  > that.
> 
> That if you don't consider the window modal you will run into all sorts
> of problems like the one that is the subject of this thread.  I'll give
> you a more realistic scenario.  Assume that you have a directory ~/foo/
> with two files say foo1 and foo2 and a directory ~/bar/ with two files
> say bar1 and bar2.  Now do
> 
> emacs -Q
> M-x customize-option RET abbrev-file-name RET
> Put ~/foo/ into the editable field, point at its end and do
> M-x widget-complete RET
> Now do
> C-x 5 2
> M-x customize-option RET custom-file RET
> Select "File", put ~/bar/ into the editable field, point at its end and
> do
> M-x widget-complete RET
> again.  Note that at this moment you have changed the contents of the
> *Completions* windows in _both_ frames.  If you now return to the first
> frame and select a completion like bar1, nothing will happen (in the
> best case).

You already made clear, further down in your previous mail, what
you mean by "modal".  And I already said OK, I understand now
what you mean by "modal", even if that is not what is usually
mean by a modal dialog/UI.

In a (truly) modal UI you would not be able to move from one to
the other like that.  That was my point: *Completions* is not
modal (in the usual sense).  In fact, in Emacs there are very
few dialogs that are modal.  `yes-or-no-p', `y-or-n-p', and
maybe query-replace are about the only things that come to mind.

> This is the same cockpit error as the one from your scenario:
> *Completions* windows are modal and should be treated accordingly,
> that is, nicely.

"Modal" in your special sense of "(a) *Completions* remains
visible until (b) it is no longer needed, when it disappears."

And yes, we agree that a user can mess up if s?he fools around.
That comes, BTW, precisely from the fact that these dialogs are
_not_ modal (in the usual sense).  Because they are not modal,
you can mix them up - neither insists on all your attention
until it is done.

>  > Ah, so that's what you mean by "modal window".  Not that a user
>  > is prevented from doing something else than interact with it,
> 
> A user is allowed to do something else as long as she behaves nicely.
> That's the price she has to pay for not being "prevented from doing
> something else than interact with it".  The user in the scenario
> above does not behave nicely

Agreed.  I would put it differently (Emacs gives you enough
rope to hang yourself), but yes, if you want to put it that way.

> and neither do you when you want to report a bug while the
> *Completions* windows is shown.

Nope.  I disagree completely.  There is nothing wrong with
doing what I described.  I even gave a couple related use
cases.

It is always possible with Emacs to mess yourself up by doing
something stupid.  That doesn't mean that leaving *Completions*
open while filing a bug report is stupid.  In your scenario
above the mess came from trying to reuse *Completions* and
expecting no crosstalk.

And even in the scenario above, BTW, it is possible to
accomplish what the user tried sanely, using a recursive
minibuffer.  Start one completion; recursive minibuffer
for another completion; finish that; resume the first
completion.  No big deal.

> Such users are punished.

Oh c'mon, Martin.  This is a bug, not punishment for being
a bad user and not treating Emacs nicely.

>  > 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.
> 
> All assumptions are off when you violate (a) or (b).

And?  Did you mean, by (a), only that the window is not removed
automatically?  Or did you mean that a user cannot remove it?

If the former (which is what I hope you meant), it's up to
Emacs not to violate (a) (i.e., not to remove it automatically
until (b)).

And I think it must be the former, because I don't see that Emacs
prevents the user from removing the window.  And if the user
removes the window then presumbably it is no longer needed.

Or maybe you mean that the user removes it accidentally?
Even then, I don't see the problem.  If there were a real
problem with removing the window then Emacs should not
let the user remove it.

And I don't even understand what it means (for Emacs or for
the user) to violate (b).

This is all a bit too vague and hypothetical for me, I'm
afraid.  I don't have the impression I'm being much help
now, as I can't really follow your point.