GNU bug report logs - #9639
24.0.90; Problem with bury-buffer in minibuffer-hide-completions

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9639 in the body.
You can then email your comments to 9639 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
Date: Sat, 01 Oct 2011 00:09:56 +0200

1. emacs -Q
2. Type `M-x glo TAB' and at the completion "M-x global-" type TAB again,
   making a *Completions* buffer pop up.
3. Type `v TAB', yielding the completion "M-x global-visual-line-mode".
=> The window that had been displaying the *Completions* buffer now
displays the *Messages* buffer.

AFAICT this is due to the following cond clause in bury-buffer (which is
called by minibuffer-hide-completions):

     ((not (window-dedicated-p))
      (switch-to-prev-buffer nil 'bury))

Only after typing RET in the minibuffer to accept the completion is the
window that had been displaying the *Completions* buffer and now
displays the *Messages* buffer deleted; in Emacs 23.2 it is deleted as
soon as the sole completion is displayed in the minibuffer.  Commenting
out the above clause restores the 23.2 behavior.  But this presumably
has bad effects elsewhere.

(Interestingly, the C code of bury-buffer prior to the move to Lisp in
revision 104559 (and long before that) has the equivalent of the above
clause.)


In GNU Emacs 24.0.90.1 (i686-suse-linux-gnu, GTK+ Version 2.22.1)
 of 2011-09-30 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10903000
configured using `configure  '--without-toolkit-scroll-bars' 'CFLAGS=-g''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Message #8 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 9639 <at> debbugs.gnu.org
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sat, 01 Oct 2011 11:08:09 +0200

> 1. emacs -Q
> 2. Type `M-x glo TAB' and at the completion "M-x global-" type TAB again,
>    making a *Completions* buffer pop up.
> 3. Type `v TAB', yielding the completion "M-x global-visual-line-mode".
> => The window that had been displaying the *Completions* buffer now
> displays the *Messages* buffer.
>
> AFAICT this is due to the following cond clause in bury-buffer (which is
> called by minibuffer-hide-completions):
>
>      ((not (window-dedicated-p))
>       (switch-to-prev-buffer nil 'bury))

... plus the fact that switching buffers should not delete windows ...

> Only after typing RET in the minibuffer to accept the completion is the
> window that had been displaying the *Completions* buffer and now
> displays the *Messages* buffer deleted; in Emacs 23.2 it is deleted as
> soon as the sole completion is displayed in the minibuffer.  Commenting
> out the above clause restores the 23.2 behavior.  But this presumably
> has bad effects elsewhere.

Presumably `minibuffer-hide-completions' should iconify a standalone
completions frame while deleting a split-off completions window.  So
maybe the following DTRT:

(defun minibuffer-hide-completions ()
  "Get rid of an out-of-date *Completions* buffer."
  ;; FIXME: We could/should use minibuffer-scroll-window here, but it
  ;; can also point to the minibuffer-parent-window, so it's a bit tricky.
  (let* ((window (get-buffer-window "*Completions*" 0))
	 (buffer (window-buffer window)))
    (when window
      (let ((deletable (window-deletable-p window)))
	(cond
	 ((eq deletable 'frame)
	  ;; Iconify frame.
	  (iconify-frame (window-frame window))
	  (bury-buffer-internal buffer))
	 (deletable
	  ;; Delete window
	  (delete-window window)
	  (bury-buffer-internal buffer))
	 (t
	  ;; Switch to another buffer.
	  (switch-to-prev-buffer window 'bury)))))))

> (Interestingly, the C code of bury-buffer prior to the move to Lisp in
> revision 104559 (and long before that) has the equivalent of the above
> clause.)

ISTR that completion windows were dedicated then and typing "v TAB"
would trigger the following code in `minibuffer-completion-help'

      ;; If there are no completions, or if the current input is already the
      ;; only possible completion, then hide (previous&stale) completions.
      (let ((window (and (get-buffer "*Completions*")
                         (get-buffer-window "*Completions*" 0))))
        (when (and (window-live-p window) (window-dedicated-p window))
          (condition-case ()
              (delete-window window)
            (error (iconify-frame (window-frame window))))))

which I can't find anymore.  But I might be wrong.

martin

Message #11 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 9639 <at> debbugs.gnu.org
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sat, 01 Oct 2011 12:03:06 +0200

On Sat, 01 Oct 2011 11:08:09 +0200 martin rudalics <rudalics <at> gmx.at> wrote:

>> 1. emacs -Q
>> 2. Type `M-x glo TAB' and at the completion "M-x global-" type TAB again,
>>    making a *Completions* buffer pop up.
>> 3. Type `v TAB', yielding the completion "M-x global-visual-line-mode".
>> => The window that had been displaying the *Completions* buffer now
>> displays the *Messages* buffer.
>>
>> AFAICT this is due to the following cond clause in bury-buffer (which is
>> called by minibuffer-hide-completions):
>>
>>      ((not (window-dedicated-p))
>>       (switch-to-prev-buffer nil 'bury))
>
> ... plus the fact that switching buffers should not delete windows ...
>
>> Only after typing RET in the minibuffer to accept the completion is the
>> window that had been displaying the *Completions* buffer and now
>> displays the *Messages* buffer deleted; in Emacs 23.2 it is deleted as
>> soon as the sole completion is displayed in the minibuffer.  Commenting
>> out the above clause restores the 23.2 behavior.  But this presumably
>> has bad effects elsewhere.
>
> Presumably `minibuffer-hide-completions' should iconify a standalone
> completions frame while deleting a split-off completions window.  So
> maybe the following DTRT:
>
> (defun minibuffer-hide-completions ()
>   "Get rid of an out-of-date *Completions* buffer."
>   ;; FIXME: We could/should use minibuffer-scroll-window here, but it
>   ;; can also point to the minibuffer-parent-window, so it's a bit tricky.
>   (let* ((window (get-buffer-window "*Completions*" 0))
> 	 (buffer (window-buffer window)))
>     (when window
>       (let ((deletable (window-deletable-p window)))
> 	(cond
> 	 ((eq deletable 'frame)
> 	  ;; Iconify frame.
> 	  (iconify-frame (window-frame window))
> 	  (bury-buffer-internal buffer))
> 	 (deletable
> 	  ;; Delete window
> 	  (delete-window window)
> 	  (bury-buffer-internal buffer))
> 	 (t
> 	  ;; Switch to another buffer.
> 	  (switch-to-prev-buffer window 'bury)))))))

I confirm this DTRT for my case.

Steve Berman

Message #14 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 9639 <at> debbugs.gnu.org
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sat, 01 Oct 2011 12:57:47 +0200

> I confirm this DTRT for my case.

I believe the original idea was to mark the window as dedicated but
`display-buffer-mark-dedicated' is currently not handled by the new
buffer display routines.  None of them calls `window--display-buffer-2'
with the DEDICATED argument set.  OTOH in the discussion of bug#7368 it
was said that dedicating the completions window might harm its reuse by
other `display-buffer' calls so I leave this to Stefan to decide what
shall be done.

martin

Message #17 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>,
	"'Stephen Berman'" <stephen.berman <at> gmx.net>
Cc: 9639 <at> debbugs.gnu.org
Subject: RE: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sat, 1 Oct 2011 07:38:33 -0700

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

Message #20 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 9639 <at> debbugs.gnu.org, Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sat, 01 Oct 2011 10:41:11 -0400

>> I confirm this DTRT for my case.

BTW, can't we just use `quit-window'?

> I believe the original idea was to mark the window as dedicated but

That's how it worked in Emacs-23, indeed.

> `display-buffer-mark-dedicated' is currently not handled by the new
> buffer display routines.

Yes, that's a bug.

> with the DEDICATED argument set.  OTOH in the discussion of bug#7368 it
> was said that dedicating the completions window might harm its reuse by
> other `display-buffer' calls so I leave this to Stefan to decide what
> shall be done.

In Emacs-23, marking the window as dedicated via
display-buffer-mark-dedicated was handy but indeed had the disadvantage
of preventing the window's reuse by display-buffer.  I think in Emacs-24
this disadvantage is less serious because the completion code is a lot
more careful to not leave the *Completion* displayed too long.
So making display-buffer-mark-dedicated work (which we need to do in any
case) should be all that's needed to fix the bug.

But of course, if we can get the *Completions* window/frame deleted
without marking it as dedicated, that'd be fine as well.


        Stefan

Message #23 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 9639 <at> debbugs.gnu.org, Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sat, 01 Oct 2011 19:04:49 +0200

> BTW, can't we just use `quit-window'?

This would delete a stand-alone frame and not iconify it.

> But of course, if we can get the *Completions* window/frame deleted
> without marking it as dedicated, that'd be fine as well.

We could give `quit-window' a third argument telling it to iconify the
frame instead of deleting it or add an option to deal with this case.
Since I still intend to eventually replace window excursions by
`display-buffer' + `quit-window' (which will probably take years) some
general pattern would be useful anyway.

martin

Message #26 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'martin rudalics' <rudalics <at> gmx.at>, 9639 <at> debbugs.gnu.org,
	'Stephen Berman' <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sun, 02 Oct 2011 07:38:18 +0800

On 2011-10-01 22:38 +0800, Drew Adams wrote:
> 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.

I have never been in a situation where iconification makes sense.

Leo

Message #29 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 9639 <at> debbugs.gnu.org, Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sat, 01 Oct 2011 20:38:33 -0400

>> BTW, can't we just use `quit-window'?
> This would delete a stand-alone frame and not iconify it.

That's a problem of quit-window.  I know that some users like this
behavior, but making the distinction based on whether the code happened
to use quit-window instead of bury-buffer is wrong, IMO.

Both bury-buffer and quit-window should hide dedicated frames in the
same way, either both by iconifying, or both by deleting the frame (and
they should share the same code to do it).

This shared code can provide a hook to let the user choose how the frame
gets hidden, but the default should be to iconify since that's how it's
worked until now (and also because I think it's a safer default, in the
sense that iconifying throws away less information than deleting the
frame).

>> But of course, if we can get the *Completions* window/frame deleted
>> without marking it as dedicated, that'd be fine as well.
> We could give `quit-window' a third argument telling it to iconify the
> frame instead of deleting it or add an option to deal with this case.

An argument doesn't seem right, since the choice doesn't depend on the
caller, AFAIK, but on the user.

> Since I still intend to eventually replace window excursions by
> `display-buffer' + `quit-window' (which will probably take years) some
> general pattern would be useful anyway.

Yes, we agree on this overarching goal, tho I think the issue is not so
much save-window-excursion (which generally needs to be solved by
changing the code so it doesn't call display-buffer at all) but rather
"stash current-window-configuration + set-window-configuration".


        Stefan

Message #32 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 9639 <at> debbugs.gnu.org, Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sun, 02 Oct 2011 12:09:45 +0200

>> This would delete a stand-alone frame and not iconify it.
>
> That's a problem of quit-window.  I know that some users like this
> behavior, but making the distinction based on whether the code happened
> to use quit-window instead of bury-buffer is wrong, IMO.
>
> Both bury-buffer and quit-window should hide dedicated frames in the
> same way, either both by iconifying, or both by deleting the frame (and
> they should share the same code to do it).
>
> This shared code can provide a hook to let the user choose how the frame
> gets hidden, but the default should be to iconify since that's how it's
> worked until now (and also because I think it's a safer default, in the
> sense that iconifying throws away less information than deleting the
> frame).

With emacs 23 help frames are deleted by default.  So if I interpret you
strictly, `quit-window' should iconify a dedicated frame and delete a
non-dedicated one.  Is that correct?

Basically, it would be nice to get rid of either `bury-buffer' or
`quit-window'.  Having two functions do approximately the same thing is
neither reasonable for developers nor for users.

martin

Message #35 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 9639 <at> debbugs.gnu.org, Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sun, 02 Oct 2011 09:39:16 -0400

> With Emacs 23 help frames are deleted by default.

Could be.  Various packages do things differently.  But the
non-package-specific code is the one that interests me.

> So if I interpret you strictly, `quit-window' should iconify
> a dedicated frame and delete a non-dedicated one.  Is that correct?

No.  Either both are deleted or both are iconified, since (again) it is
mostly a choice that depends on the general window-manager usage and
user preference.

> Basically, it would be nice to get rid of either `bury-buffer' or
> `quit-window'.  Having two functions do approximately the same thing is
> neither reasonable for developers nor for users.

I think both are in fairly wide use, so getting rid of one of them is
not really an option.  But I hope we can define one in terms of
the other (or both in terms of a third internal one).


        Stefan

Message #38 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
	"'martin rudalics'" <rudalics <at> gmx.at>
Cc: 9639 <at> debbugs.gnu.org, 'Stephen Berman' <stephen.berman <at> gmx.net>
Subject: RE: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sun, 2 Oct 2011 08:35:00 -0700

> This shared code can provide a hook to let the user choose 
> how the frame gets hidden, 

Why make users jump through hoops and hooks?  Provide a user option.  (And
removing is not "hiding".  And even hiding does not leave behind little icons.)

> but the default should be to iconify since that's how it's
> worked until now

Oh, that's rich.  If you resist bug reports long enough, sure, you can then
claim that "that's how it's worked until now", and that's the reason it should
continue to be the default ("since").

But no, that's not how it worked, even as recently as Emacs 22, IIRC.  At least
in Emacs 18,...21,22 quitting the debugger, say, does _not_ iconify a dedicated
*Backtrace* frame - it simply _deletes_ it - behavior that makes sense.

Seems to me this iconification is something that you introduced.
Iconifying is hardly "how it worked" before that.

emacs -Q ; Emacs 22
(setq special-display-regexps '("[ ]?[*][^*]+[*]"))
M-: (/ 0)
q ; in buffer *Backtrace*.  Poof - the frame is _deleted_.

So by your logic, "since" that's _not_ how it worked throughout Emacs's history
until you introduced the iconification bug/feature, the traditional default
behavior should be restored: delete the frame.

> (and also because I think it's a safer default, in the
> sense that iconifying throws away less information than deleting the
> frame).

You did add "in the sense that", but it's not about _safety_.  Deleting a frame
does not destroy any important information (buffer/file content etc.).

And nothing prevents you from saving the frame position, shape, and size for
your own use - e.g. in a register.  Do that in a hook if you like.

But the default behavior should simply do what a user expects: _remove_ the
frame.  That could be done by making it invisible or deleting it.

Making it invisible would save all of your precious frame info, BTW.
Invisibility, like deletion (and unlike iconification), is instantaneous and
unclutters the display, and it would presumably be a reasonable compromise.  In
principle, it should address both your concerns and mine.

Supposedly, there are some bugs associated with invisible frames, but it's not
clear just what they are (?).  Maybe it's time to find out (and fix them).

In sum, invisibility would probably be an acceptable compromise default.
Iconifying as default should be a non-starter - a bad idea.

> the choice doesn't depend on the caller, AFAIK, but on the user.

Which means it should be easily customizable by the user - a user option, not
just hooks.

Message #41 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'martin rudalics' <rudalics <at> gmx.at>, 9639 <at> debbugs.gnu.org,
	'Stephen Berman' <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sun, 02 Oct 2011 20:41:10 -0400

> Why make users jump through hoops and hooks?  Provide a user option.

That's a false dichotomy.


        Stefan

Message #44 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 'martin rudalics' <rudalics <at> gmx.at>, 9639 <at> debbugs.gnu.org,
	'Stephen Berman' <stephen.berman <at> gmx.net>
Subject: RE: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Sun, 2 Oct 2011 17:48:42 -0700

> > Why make users jump through hoops and hooks?  Provide a user option.
> 
> That's a false dichotomy.

That's sophistry.  No one presented any dichotomy.

Provide hoops and hooks if you like.  But provide a user option, for users.  No
one said it's either/or.

Message #49 received at 9639-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: 9639-done <at> debbugs.gnu.org
Cc: Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Tue, 04 Oct 2011 17:50:10 +0200

> 1. emacs -Q
> 2. Type `M-x glo TAB' and at the completion "M-x global-" type TAB again,
>    making a *Completions* buffer pop up.
> 3. Type `v TAB', yielding the completion "M-x global-visual-line-mode".
> => The window that had been displaying the *Completions* buffer now
> displays the *Messages* buffer.

Should be fixed in revision 105995.  Please try again.

martin

Message #52 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 9639 <at> debbugs.gnu.org, Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Tue, 04 Oct 2011 17:50:34 +0200

> No.  Either both are deleted or both are iconified, since (again) it is
> mostly a choice that depends on the general window-manager usage and
> user preference.
>
>> Basically, it would be nice to get rid of either `bury-buffer' or
>> `quit-window'.  Having two functions do approximately the same thing is
>> neither reasonable for developers nor for users.
>
> I think both are in fairly wide use, so getting rid of one of them is
> not really an option.  But I hope we can define one in terms of
> the other (or both in terms of a third internal one).

I now try to handle burying buffers via `quit-window' and `bury-buffer'
in a uniform manner.  All this in a new function called `window--delete'
(which is also called by `replace-buffer-in-windows' although the latter
always deletes the frame if possible).

martin

Message #55 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 9639 <at> debbugs.gnu.org, 'Stefan Monnier' <monnier <at> iro.umontreal.ca>,
	'Stephen Berman' <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Tue, 04 Oct 2011 17:51:08 +0200

> But provide a user option, for users.

I now revived an option for this. It's called `frame-auto-delete', is by
default nil and, when non-nil, causes frames to be deleted in two cases:

- `quit-window' when its first argument is nil and the frame has been
  specially created for the window's buffer.

- `bury-buffer' when its argument is nil and the selected window is
  dedicated to its buffer.

martin

Message #58 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 9639 <at> debbugs.gnu.org, Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Tue, 04 Oct 2011 17:51:22 +0200

> In Emacs-23, marking the window as dedicated via
> display-buffer-mark-dedicated was handy but indeed had the disadvantage
> of preventing the window's reuse by display-buffer.  I think in Emacs-24
> this disadvantage is less serious because the completion code is a lot
> more careful to not leave the *Completion* displayed too long.
> So making display-buffer-mark-dedicated work (which we need to do in any
> case) should be all that's needed to fix the bug.
>
> But of course, if we can get the *Completions* window/frame deleted
> without marking it as dedicated, that'd be fine as well.

I think both `quit-window' and `bury-buffer' should handle this the same
way now.  So if bug#7368 has not been resolved yet we should be able to
display completions in a non-dedicated window and quit that afterwards.

martin

Message #61 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 9639 <at> debbugs.gnu.org, 'Stefan Monnier' <monnier <at> iro.umontreal.ca>,
	'Stephen Berman' <stephen.berman <at> gmx.net>
Subject: RE: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Tue, 4 Oct 2011 09:03:25 -0700

>  > But provide a user option, for users.
> 
> I now revived an option for this. It's called 
> `frame-auto-delete', is by default nil and, when non-nil,
> causes frames to be deleted in two cases:
> 
> - `quit-window' when its first argument is nil and the frame has been
>    specially created for the window's buffer.
> 
> - `bury-buffer' when its argument is nil and the selected window is
>    dedicated to its buffer.

Progress; thanks (haven't tried it, but sounds like progress).

But:
* You don't say what the non-deletion behavior is.
* The default behavior should be deletion.

`delete-frame' should be treated analogously to `delete-window'.

Message #64 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 9639 <at> debbugs.gnu.org, Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Tue, 04 Oct 2011 13:45:35 -0400

> I now try to handle burying buffers via `quit-window' and `bury-buffer'
> in a uniform manner.  All this in a new function called `window--delete'
> (which is also called by `replace-buffer-in-windows' although the latter
> always deletes the frame if possible).

Thanks, this looks good,


        Stefan

Message #65 received at 9639-done <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 9639-done <at> debbugs.gnu.org
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Tue, 04 Oct 2011 22:19:16 +0200

On Tue, 04 Oct 2011 17:50:10 +0200 martin rudalics <rudalics <at> gmx.at> wrote:

>> 1. emacs -Q
>> 2. Type `M-x glo TAB' and at the completion "M-x global-" type TAB again,
>>    making a *Completions* buffer pop up.
>> 3. Type `v TAB', yielding the completion "M-x global-visual-line-mode".
>> => The window that had been displaying the *Completions* buffer now
>> displays the *Messages* buffer.
>
> Should be fixed in revision 105995.  Please try again.

I updated and confirm the problem I reported is now fixed; thanks.

Steve Berman

Message #68 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 9639 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Tue, 11 Oct 2011 19:36:27 -0600

On 10/4/2011 9:51 AM, martin rudalics wrote:
>  > But provide a user option, for users.
>
> I now revived an option for this. It's called `frame-auto-delete', is by
> default nil and, when non-nil, causes frames to be deleted in two cases:
>
> - `quit-window' when its first argument is nil and the frame has been
> specially created for the window's buffer.
>
> - `bury-buffer' when its argument is nil and the selected window is
> dedicated to its buffer.

I can't see this variable in the Emacs trunk. Was this committed?

Message #73 received at 9639 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: 9639 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Wed, 12 Oct 2011 08:52:54 +0200

>> I now revived an option for this. It's called `frame-auto-delete', is by
>> default nil and, when non-nil, causes frames to be deleted in two cases:
[...]
> I can't see this variable in the Emacs trunk. Was this committed?

Upon Stefan's request this variable was renamed to
`frame-auto-hide-function' and is now supposed to specify a function
that takes a frame as argument.  The default value is `iconify-frame'
and `delete-frame' is a preinstalled choice.

martin

Message #74 received at 9639-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: 9639-done <at> debbugs.gnu.org
Cc: Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#9639: 24.0.90;
	Problem with bury-buffer in minibuffer-hide-completions
Date: Wed, 12 Oct 2011 09:02:12 +0200

> I updated and confirm the problem I reported is now fixed; thanks.

Thanks, martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.