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

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

[Drew Adams]

emacs -Q
 
M-x customize-option RET abbrev-file-name RET
 
Put point after the c:/ in the default value c:/.abbrev_defs, and hit
C-k.
 
M-x widget-complete RET
 
(See bug #6830 - the completion candidates are the files in the current
dir, not the files in c:/.)
 
You now have two windows in the only frame: (1) Customize, (2)
*Completions*.
 
Still with point in the edit field of the Customize buffer:
 
M-x report-emacs-bug RET fffffffffff RET
 
In the only existing frame, you now have two windows: (1) *Bug Help*,
(2) *Completions*, with the first of these selected.
 
The only important buffer to show at this point is completely hidden:
*unsent mail to bug-gnu-emacs@gnu.org*.  No way for a user to report the
bug, unless s?he knows both (a) that there is a buffer somewhere,
waiting for user input to report the bug and (b) how to show that
buffer.
 
Not very user-friendly.  This is a regression starting with Emacs 23.
(It worked OK in Emacs 22 and before, but you will need to tweak the
recipe - e.g. use `custom-file' and choose `File' from the Value menu.)

In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
 of 2012-02-15 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

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

[Drew Adams]

ping

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

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> emacs -Q
>
> M-x customize-option RET abbrev-file-name RET
>
> Put point after the c:/ in the default value c:/.abbrev_defs, and hit
> C-k.
>
> M-x widget-complete RET
>
> (See bug #6830 - the completion candidates are the files in the current
> dir, not the files in c:/.)
>
> You now have two windows in the only frame: (1) Customize, (2)
> *Completions*.
>
> Still with point in the edit field of the Customize buffer:
>
> M-x report-emacs-bug RET fffffffffff RET
>
> In the only existing frame, you now have two windows: (1) *Bug Help*,
> (2) *Completions*, with the first of these selected.
>
> The only important buffer to show at this point is completely hidden:
> *unsent mail to bug-gnu-emacs@gnu.org*.  No way for a user to report the
> bug, unless s?he knows both (a) that there is a buffer somewhere,
> waiting for user input to report the bug and (b) how to show that
> buffer.

Is this still a problem in Emacs 24.3?  The code in this area has gotten
a lot of churn...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Drew Adams]

> > emacs -Q
> >
> > M-x customize-option RET abbrev-file-name RET
> >
> > Put point after the c:/ in the default value c:/.abbrev_defs, and
> > hit C-k.
> >
> > M-x widget-complete RET
> >
> > (See bug #6830 - the completion candidates are the files in the
> > current dir, not the files in c:/.)
> >
> > You now have two windows in the only frame: (1) Customize, (2)
> > *Completions*.
> >
> > Still with point in the edit field of the Customize buffer:
> >
> > M-x report-emacs-bug RET fffffffffff RET
> >
> > In the only existing frame, you now have two windows: (1) *Bug
> > Help*, (2) *Completions*, with the first of these selected.
> >
> > The only important buffer to show at this point is completely
> > hidden: *unsent mail to bug-gnu-emacs@gnu.org*.  No way for a
> > user to report the bug, unless s?he knows both (a) that there
> > is a buffer somewhere, waiting for user input to report the bug
> > and (b) how to show that buffer.
> 
> Is this still a problem in Emacs 24.3?  The code in this area has
> gotten a lot of churn...

Yes, apparently so (in a build from 2014-02-07, at least).

I just followed the fine recipe and saw exactly what was reported.
Perhaps it is platform-specific, if that is not what you see.

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

[Drew Adams]

> Sent: Tuesday, February 11, 2014 6:33 AM
>
> > Is this still a problem in Emacs 24.3?  The code in this area has
> > gotten a lot of churn...
> 
> Yes, apparently so (in a build from 2014-02-07, at least).
> 
> I just followed the fine recipe and saw exactly what was reported.
> Perhaps it is platform-specific, if that is not what you see.


This bug is still 100% reproducible in an Emacs 25 build of 2015-12-10:

In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
 of 2015-12-10
Bzr revision: 6148555ee5a3d0139ae517803718b3e0357933c7
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk --enable-checking=yes
 --enable-check-lisp-object-type --without-compress-install 'CFLAGS=-Og
 -ggdb3' LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

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

[Eli Zaretskii]

> Date: Fri, 25 Dec 2015 15:34:53 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 10873@debbugs.gnu.org
> 
> > Sent: Tuesday, February 11, 2014 6:33 AM
> >
> > > Is this still a problem in Emacs 24.3?  The code in this area has
> > > gotten a lot of churn...
> > 
> > Yes, apparently so (in a build from 2014-02-07, at least).
> > 
> > I just followed the fine recipe and saw exactly what was reported.
> > Perhaps it is platform-specific, if that is not what you see.
> 
> 
> This bug is still 100% reproducible in an Emacs 25 build of 2015-12-10:

Martin, could you please look into this?

TIA

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

[martin rudalics]

 >> This bug is still 100% reproducible in an Emacs 25 build of 2015-12-10:
 >
 > Martin, could you please look into this?

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.

So it's your choice ...

martin

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

[martin rudalics]

 > ... we can do that
 > easily by calling ‘delete-other-windows’ before ‘display-buffer’.

Just to clarify the term "easily": ‘report-emacs-bug’ will also have to
make sure that the one remaining window it's going to use and split is
not dedicated, the frame can be split in the first place and possibly
some other things we might have never thought of before ...

martin

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

[Eli Zaretskii]

> Date: Sun, 27 Dec 2015 17:05:02 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: larsi@gnus.org, 10873@debbugs.gnu.org
> 
> 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.

Can we save the window configuration before deleting other windows,
and restore it once the report is sent?  If not, then I think just
deleting the other windows is "good enough" in this case.

Thanks.

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

[Drew Adams]

>  >> 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.

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

[Drew Adams]

> Can we save the window configuration before deleting other windows,
> and restore it once the report is sent?  If not, then I think just
> deleting the other windows is "good enough" in this case.

And what if the user wants to refer to something in another window,
to complete the bug report?

How about returning to the pre-Emacs 23 behavior?

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

[martin rudalics]

 > Can we save the window configuration before deleting other windows,
 > and restore it once the report is sent?

Conceptually, ‘save-window-excursion’ should not be used around
‘display-buffer’ although it might be harmless in the case at hand.

 > If not, then I think just
 > deleting the other windows is "good enough" in this case.

I have no opinion other than that fixing this particular problem might
introduce problems for people who would, for example, like to write a
report based on the appearance of text shown in a particular window.  If
we deliberately delete such a window before the user is able to fill in
the text for the report, she may have a hard time recreating it.

And obviously deleting all other windows will be silly when the bug
report window should pop up on a new frame anyway.  Note in this
context: We don't know beforehand whether that will happen!

So to be sure: Does the present report warrant the proposed solution?

martin

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

[martin rudalics]

 > *Completions* is not a modal window.

I don't mind to disagree here.

 > 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.

Agreed.  That's precisely why the *Completions* window is dedicated.

 > 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.

Agreed, again.

 > 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,

The modal activity in the case at hand is picking up a completion.

 > 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.

Easy.  Find someone who makes the *Completions* window non-dedicated
again.  My interest in this bug is exhausted already.

martin

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

[Eli Zaretskii]

> Date: Sun, 27 Dec 2015 18:06:15 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, larsi@gnus.org, 10873@debbugs.gnu.org
> 
>  > Can we save the window configuration before deleting other windows,
>  > and restore it once the report is sent?
> 
> Conceptually, ‘save-window-excursion’ should not be used around
> ‘display-buffer’ although it might be harmless in the case at hand.

If it's harmless in this case, why not do it?

> I have no opinion other than that fixing this particular problem might
> introduce problems for people who would, for example, like to write a
> report based on the appearance of text shown in a particular window.

They can always display that window when they want to.  They know it
existed, so they will know where and how to look.

OTOH, having the bug-report buffer not show at all is much worse: a
user who is not very fluent in reporting bugs, or maybe even does that
for the first time, will never know what to look for.

> So to be sure: Does the present report warrant the proposed solution?

If you can propose a better one that has fewer potential problems, I'm
all ears.  If not, let's solve this bug that way.  We must solve it.

Thanks.

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

[Eli Zaretskii]

> Date: Sun, 27 Dec 2015 08:57:17 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: larsi@gnus.org, 10873@debbugs.gnu.org
> 
> > Can we save the window configuration before deleting other windows,
> > and restore it once the report is sent?  If not, then I think just
> > deleting the other windows is "good enough" in this case.
> 
> And what if the user wants to refer to something in another window,
> to complete the bug report?
> 
> How about returning to the pre-Emacs 23 behavior?

You assume it's possible, without reverting all the changes since
Emacs 23.

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

[Drew Adams]

> I have no opinion other than that fixing this particular problem 

by just removing other windows

> might introduce problems for people who would, for example, like
> to write a report based on the appearance of text shown in a
> particular window.  If we deliberately delete such a window before
> the user is able to fill in the text for the report, she may have
> a hard time recreating it.

Exactly!  And the same for *Completions*.

> And obviously deleting all other windows will be silly when the bug
> report window should pop up on a new frame anyway.  Note in this
> context: We don't know beforehand whether that will happen!

Agreed, again.

> So to be sure: Does the present report warrant the proposed solution?

The right solution is _not_ to remove other windows.

Perhaps the right solution is to pop up a separate frame.
Or perhaps the "instructions" window should be combined with
the "report" window.  Or perhaps the pre-Emacs 23 code could
serve as a guide (dunno).

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

[Drew Adams]

>  > *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?

>  > 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.
> 
> Agreed.  That's precisely why the *Completions* window is dedicated.
> 
>  > 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.
> 
> Agreed, again.
> 
>  > 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,
> 
> 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.

>  > Since it is a regression it should not be impossible or unfeasible
>  > to obtain the pre-regression behavior again.
> 
> Easy.  Find someone who makes the *Completions* window non-dedicated
> again.  My interest in this bug is exhausted already.

I don't argue that the implementation should return to what it
was before Emacs 23.  Nor do I argue that the *Completions*
window should not be dedicated.

I argue only that (1) the bug-reporting window(s) should be visible
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.

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

[Drew Adams]

> > How about returning to the pre-Emacs 23 behavior?
> 
> You assume it's possible, without reverting all the changes since
> Emacs 23.

No, I didn't mean that the same implementation should be
restored.  I meant only that the behavior might serve as
a guide.  Dunno; if that doesn't help then ignore it.

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

[Drew Adams]

> They can always display that window when they want to.  They know it
> existed, so they will know where and how to look.

Yes, that's probably OK, if the window is not deleted.

But that can be quite cumbersome for users.  Some might not even
know how to display it.  I would hope that this approach to a
solution is not necessary.

I would sooner see the report window and the help window combined.
And perhaps shown in a separate frame.  I think that would interfere
the least with the user's context.

> OTOH, having the bug-report buffer not show at all is much worse: a
> user who is not very fluent in reporting bugs, or maybe even does that
> for the first time, will never know what to look for.
> 
> > So to be sure: Does the present report warrant the proposed solution?
> 
> If you can propose a better one that has fewer potential problems, I'm
> all ears.  If not, let's solve this bug that way.  We must solve it.

See above: Why not a separate frame for reporting?  (At least for
the graphic-display case.  I don't even know whether or how this
bug manifests itself for the console case.)

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

[martin rudalics]

 >> Conceptually, ‘save-window-excursion’ should not be used around
 >> ‘display-buffer’ although it might be harmless in the case at hand.
 >
 > If it's harmless in this case, why not do it?

I said "it might be harmless".  In private code I would never do such a
thing.  And ‘save-window-excursion’ can't be used here anyway: We would
have to save the configuration current before displaying the mail buffer
and restore it after the mail was sent.  Now suppose the reporter asked
for other completions while editing the mail.  It's the last of those
completions that would be shown after the configuration has been
restored and not the one shown at the time of saving the configuration.

 >> I have no opinion other than that fixing this particular problem might
 >> introduce problems for people who would, for example, like to write a
 >> report based on the appearance of text shown in a particular window.
 >
 > They can always display that window when they want to.  They know it
 > existed, so they will know where and how to look.
 >
 > OTOH, having the bug-report buffer not show at all is much worse: a
 > user who is not very fluent in reporting bugs, or maybe even does that
 > for the first time, will never know what to look for.

Such a user must first have to be smart enough to write a bug report
with an open *Completions* window.  Any such user will know what to look
for.

 >> So to be sure: Does the present report warrant the proposed solution?
 >
 > If you can propose a better one that has fewer potential problems, I'm
 > all ears.  If not, let's solve this bug that way.  We must solve it.

I have no better solution.

martin

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

[martin rudalics]

 >>   > *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.

 >> 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.  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.
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.

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.

 > 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?

martin

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

[martin rudalics]

 > See above: Why not a separate frame for reporting?  (At least for
 > the graphic-display case.  I don't even know whether or how this
 > bug manifests itself for the console case.)

Separate frames work on the console.  Personally I'm all for such a
solution - as default behavior.  I'm afraid others are not.

martin

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

[Drew Adams]

>  >>   > *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.

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

[Drew Adams]

>  > See above: Why not a separate frame for reporting?  (At least for
>  > the graphic-display case.  I don't even know whether or how this
>  > bug manifests itself for the console case.)
> 
> Separate frames work on the console.

Except that only one is visible at a time, no?  In which case
the same problem exists.  (I'm no expert on this, so please
ignore if I'm wrong.)

> Personally I'm all for such a
> solution - as default behavior.  I'm afraid others are not.

OK, good that you are, at least.

I don't claim that that has to be the solution.  I mean only
to describe the problem.  That was just a suggestion.

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

[martin rudalics]

 >> 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).

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

 > 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 and neither do you when you want to report a bug
while the *Completions* windows is shown.  Such users are punished.

 > 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).

martin

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

[martin rudalics]

 >> Separate frames work on the console.
 >
 > Except that only one is visible at a time, no?  In which case
 > the same problem exists.  (I'm no expert on this, so please
 > ignore if I'm wrong.)

No problem: First the mail window pops up and then it gets split to show
the help window.  But on graphical systems a new frame will pop up and
some people would certainly consider that a regression.

 >> Personally I'm all for such a
 >> solution - as default behavior.  I'm afraid others are not.
 >
 > OK, good that you are, at least.
 >
 > I don't claim that that has to be the solution.  I mean only
 > to describe the problem.  That was just a suggestion.

A suggestion without a patch will remain a suggestion.

martin

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.

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

[martin rudalics]

 > If you can propose a better one that has fewer potential problems, I'm
 > all ears.  If not, let's solve this bug that way.  We must solve it.

I checked in that fix.

martin

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

[martin rudalics]

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

I meant that when the window gets removed or reused there's no guarantee
that processing the completions will succeed.

 > 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)).

Or not to reuse it for showing another buffer.  That's what the
dedicated flag seems to be for.

 > 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.

That's the idea, I think.

 > 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.

I said that Emacs is nice.  It lets the user remove or reuse the window
and thus terminate the completions dialogue.

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

That this completions dialogue cannot be continued reliably.

 > 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.

I don't remember ever having contributed anything to the completions
code or to ‘report-emacs-bug’ so I cannot be more concrete.  I meanwhile
pushed the change proposed earlier.  If you don't like the new behavior
you will have to come up with a suitable solution.  Eli said that we
must solve this bug.

martin

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

[Eli Zaretskii]

> Date: Mon, 28 Dec 2015 19:23:47 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, larsi@gnus.org, 10873@debbugs.gnu.org
> 
>  > If you can propose a better one that has fewer potential problems, I'm
>  > all ears.  If not, let's solve this bug that way.  We must solve it.
> 
> I checked in that fix.

Thank you!

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

[Drew Adams]

> I meanwhile pushed the change proposed earlier.

Thanks.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 28 Dec 2015 19:23:47 +0100
>> From: martin rudalics <rudalics@gmx.at>
>> CC: drew.adams@oracle.com, larsi@gnus.org, 10873@debbugs.gnu.org
>> 
>>  > If you can propose a better one that has fewer potential problems, I'm
>>  > all ears.  If not, let's solve this bug that way.  We must solve it.
>> 
>> I checked in that fix.
>
> Thank you!

Looks like this was fixed; closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no