unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'martin rudalics'" <rudalics@gmx.at>,
	"'Stephen Berman'" <stephen.berman@gmx.net>
Cc: 9639@debbugs.gnu.org
Subject: bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
Date: Sat, 1 Oct 2011 07:38:33 -0700	[thread overview]
Message-ID: <944D5D429FE44884ABAFF93521DEBB73@us.oracle.com> (raw)
In-Reply-To: <4E86D879.7060105@gmx.at>

> Presumably `minibuffer-hide-completions' should iconify a standalone
> completions frame

I have not been following this thread, but NO, it should *delete* a standalone
completions frame, not iconify it.

Better yet, the behavior should be customizable (delete, make invisible,
iconify, put on a different tab,...), but the _default_ behavior should simply
be to *delete* the frame.

1. The analogy to `delete-window' is `delete-frame', and that is just what the
behavior here (at least the default behavior) should be: delete the frame.

2. There is no _need_ to iconify a frame that we no longer need (!).

3. Iconifying, at least on Windows, takes longer and distracts the user,
sweeping an animation across the screen.

4. If someone binds the window-manager `iconify-frame' event to do something
slightly different then things can be even worse:
(define-key special-event-map [iconify-frame] 'foobar)

5. Iconifying puts icons (of one form or another) on the desktop.  There is no
general need for a *Completions* buffer icon.  Occam's razor.  Anyone really
needing to access buffer *Completions* to see the candidate completions from the
_last_ command can just use C-x C-b.

6. If *Completions* is always created as a standalone frame, then there is no
need to save an icon for it.  The buffer is one thing, the frame/icon is
another.  If you want the frame always created in the same position with the
same size or something (the only argument Stefan has ever given for iconifying,
AFAIK), then just _create_ it that way each time.

7. Just because Stefan's own use case prefers iconifying is _no reason_ to
hard-code iconifying as the behavior.  


That's several reasons why iconifying is a bad idea.  What's the argument _for_
iconifying?  Only this: Stefan likes it.  He likes it because it saves the frame
position and size.  That's the only reason that's ever been given, AFAIK.
Position, shape, and size of a standalone frame can be handled at its creation,
as is usual in Emacs.  There is no need to  create an icon just to save that
info here.






  parent reply	other threads:[~2011-10-01 14:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-30 22:09 bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions Stephen Berman
2011-10-01  9:08 ` martin rudalics
2011-10-01 10:03   ` Stephen Berman
2011-10-01 10:57     ` martin rudalics
2011-10-01 14:41       ` Stefan Monnier
2011-10-01 17:04         ` martin rudalics
2011-10-02  0:38           ` Stefan Monnier
2011-10-02 10:09             ` martin rudalics
2011-10-02 13:39               ` Stefan Monnier
2011-10-04 15:50                 ` martin rudalics
2011-10-04 17:45                   ` Stefan Monnier
2011-10-02 15:35             ` Drew Adams
2011-10-03  0:41               ` Stefan Monnier
2011-10-03  0:48                 ` Drew Adams
2011-10-04 15:51                   ` martin rudalics
2011-10-04 16:03                     ` Drew Adams
2011-10-12  1:36                     ` Christoph Scholtes
2011-10-12  6:52                       ` martin rudalics
2011-10-04 15:51         ` martin rudalics
2011-10-01 14:38   ` Drew Adams [this message]
2011-10-01 23:38     ` Leo
2011-10-04 15:50 ` martin rudalics
2011-10-15 10:26   ` bug#5357: 23.1; Attempt to drag rightmost scrollbar martin rudalics

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=944D5D429FE44884ABAFF93521DEBB73@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=9639@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    --cc=stephen.berman@gmx.net \
    /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).