unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>
Cc: 10873@debbugs.gnu.org, larsi@gnus.org
Subject: bug#10873: 24.0.93; `report-emacs-bug' obscures bug-reporting buffer (!)
Date: Sun, 27 Dec 2015 18:06:20 +0100	[thread overview]
Message-ID: <56801A8C.2080605@gmx.at> (raw)
In-Reply-To: <0286fb63-edbc-448f-ae07-738ed5ef8f78@default>

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





  reply	other threads:[~2015-12-27 17:06 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-22 23:21 bug#10873: 24.0.93; `report-emacs-bug' obscures bug-reporting buffer (!) Drew Adams
2012-09-17  0:10 ` Drew Adams
2014-02-09  5:11 ` Lars Ingebrigtsen
2014-02-11 14:33   ` Drew Adams
2015-12-25 23:34     ` Drew Adams
2015-12-26  9:36       ` Eli Zaretskii
2015-12-27 16:05         ` martin rudalics
2015-12-27 16:12           ` martin rudalics
2015-12-27 16:25           ` Eli Zaretskii
2015-12-27 16:57             ` Drew Adams
2015-12-27 17:16               ` Eli Zaretskii
2015-12-27 17:06             ` martin rudalics
2015-12-27 17:15               ` Eli Zaretskii
2015-12-27 18:00                 ` Drew Adams
2015-12-27 18:37                   ` martin rudalics
2015-12-27 19:14                     ` Drew Adams
2015-12-28 10:08                       ` martin rudalics
2015-12-27 18:36                 ` martin rudalics
2015-12-28 18:23                 ` martin rudalics
2015-12-28 18:35                   ` Eli Zaretskii
2016-04-28 13:47                     ` Lars Ingebrigtsen
2015-12-27 18:00               ` Drew Adams
2015-12-27 16:51           ` Drew Adams
2015-12-27 17:06             ` martin rudalics [this message]
2015-12-27 18:00               ` Drew Adams
2015-12-27 18:37                 ` martin rudalics
2015-12-27 19:14                   ` Drew Adams
2015-12-28 10:08                     ` martin rudalics
2015-12-28 10:44                       ` Drew Adams
2015-12-28 18:23                         ` martin rudalics
2015-12-28 18:41                           ` Drew Adams
     [not found]     ` <<43f2b0b2-fafc-43a9-b56a-120b90878cbc@default>
     [not found]       ` <<838u4hk0um.fsf@gnu.org>
     [not found]         ` <<56800C2E.80300@gmx.at>
     [not found]           ` <<83bn9bhna2.fsf@gnu.org>
     [not found]             ` <<1cf60229-6b8c-4c53-96f2-1b8f5d74b80b@default>
     [not found]               ` <<8337unhkwt.fsf@gnu.org>
2015-12-27 18:00                 ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56801A8C.2080605@gmx.at \
    --to=rudalics@gmx.at \
    --cc=10873@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).