* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
@ 2011-09-30 22:09 Stephen Berman
2011-10-01 9:08 ` martin rudalics
2011-10-04 15:50 ` martin rudalics
0 siblings, 2 replies; 23+ messages in thread
From: Stephen Berman @ 2011-09-30 22:09 UTC (permalink / raw)
To: 9639
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
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 14:38 ` Drew Adams
2011-10-04 15:50 ` martin rudalics
1 sibling, 2 replies; 23+ messages in thread
From: martin rudalics @ 2011-10-01 9:08 UTC (permalink / raw)
To: Stephen Berman; +Cc: 9639
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
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:38 ` Drew Adams
1 sibling, 1 reply; 23+ messages in thread
From: Stephen Berman @ 2011-10-01 10:03 UTC (permalink / raw)
To: martin rudalics; +Cc: 9639
On Sat, 01 Oct 2011 11:08:09 +0200 martin rudalics <rudalics@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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-01 10:03 ` Stephen Berman
@ 2011-10-01 10:57 ` martin rudalics
2011-10-01 14:41 ` Stefan Monnier
0 siblings, 1 reply; 23+ messages in thread
From: martin rudalics @ 2011-10-01 10:57 UTC (permalink / raw)
To: Stephen Berman; +Cc: 9639
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-01 9:08 ` martin rudalics
2011-10-01 10:03 ` Stephen Berman
@ 2011-10-01 14:38 ` Drew Adams
2011-10-01 23:38 ` Leo
1 sibling, 1 reply; 23+ messages in thread
From: Drew Adams @ 2011-10-01 14:38 UTC (permalink / raw)
To: 'martin rudalics', 'Stephen Berman'; +Cc: 9639
> 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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-01 10:57 ` martin rudalics
@ 2011-10-01 14:41 ` Stefan Monnier
2011-10-01 17:04 ` martin rudalics
2011-10-04 15:51 ` martin rudalics
0 siblings, 2 replies; 23+ messages in thread
From: Stefan Monnier @ 2011-10-01 14:41 UTC (permalink / raw)
To: martin rudalics; +Cc: 9639, Stephen Berman
>> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-01 14:41 ` Stefan Monnier
@ 2011-10-01 17:04 ` martin rudalics
2011-10-02 0:38 ` Stefan Monnier
2011-10-04 15:51 ` martin rudalics
1 sibling, 1 reply; 23+ messages in thread
From: martin rudalics @ 2011-10-01 17:04 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9639, Stephen Berman
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-01 14:38 ` Drew Adams
@ 2011-10-01 23:38 ` Leo
0 siblings, 0 replies; 23+ messages in thread
From: Leo @ 2011-10-01 23:38 UTC (permalink / raw)
To: Drew Adams; +Cc: 9639, 'Stephen Berman'
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-01 17:04 ` martin rudalics
@ 2011-10-02 0:38 ` Stefan Monnier
2011-10-02 10:09 ` martin rudalics
2011-10-02 15:35 ` Drew Adams
0 siblings, 2 replies; 23+ messages in thread
From: Stefan Monnier @ 2011-10-02 0:38 UTC (permalink / raw)
To: martin rudalics; +Cc: 9639, Stephen Berman
>> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-02 0:38 ` Stefan Monnier
@ 2011-10-02 10:09 ` martin rudalics
2011-10-02 13:39 ` Stefan Monnier
2011-10-02 15:35 ` Drew Adams
1 sibling, 1 reply; 23+ messages in thread
From: martin rudalics @ 2011-10-02 10:09 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9639, Stephen Berman
>> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-02 10:09 ` martin rudalics
@ 2011-10-02 13:39 ` Stefan Monnier
2011-10-04 15:50 ` martin rudalics
0 siblings, 1 reply; 23+ messages in thread
From: Stefan Monnier @ 2011-10-02 13:39 UTC (permalink / raw)
To: martin rudalics; +Cc: 9639, Stephen Berman
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-02 0:38 ` Stefan Monnier
2011-10-02 10:09 ` martin rudalics
@ 2011-10-02 15:35 ` Drew Adams
2011-10-03 0:41 ` Stefan Monnier
1 sibling, 1 reply; 23+ messages in thread
From: Drew Adams @ 2011-10-02 15:35 UTC (permalink / raw)
To: 'Stefan Monnier', 'martin rudalics'
Cc: 9639, 'Stephen Berman'
> 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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-02 15:35 ` Drew Adams
@ 2011-10-03 0:41 ` Stefan Monnier
2011-10-03 0:48 ` Drew Adams
0 siblings, 1 reply; 23+ messages in thread
From: Stefan Monnier @ 2011-10-03 0:41 UTC (permalink / raw)
To: Drew Adams; +Cc: 9639, 'Stephen Berman'
> Why make users jump through hoops and hooks? Provide a user option.
That's a false dichotomy.
Stefan
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-03 0:41 ` Stefan Monnier
@ 2011-10-03 0:48 ` Drew Adams
2011-10-04 15:51 ` martin rudalics
0 siblings, 1 reply; 23+ messages in thread
From: Drew Adams @ 2011-10-03 0:48 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 9639, 'Stephen Berman'
> > 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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
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-04 15:50 ` martin rudalics
2011-10-15 10:26 ` bug#5357: 23.1; Attempt to drag rightmost scrollbar martin rudalics
1 sibling, 1 reply; 23+ messages in thread
From: martin rudalics @ 2011-10-04 15:50 UTC (permalink / raw)
To: 9639-done; +Cc: Stephen Berman
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-02 13:39 ` Stefan Monnier
@ 2011-10-04 15:50 ` martin rudalics
2011-10-04 17:45 ` Stefan Monnier
0 siblings, 1 reply; 23+ messages in thread
From: martin rudalics @ 2011-10-04 15:50 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9639, Stephen Berman
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
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
0 siblings, 2 replies; 23+ messages in thread
From: martin rudalics @ 2011-10-04 15:51 UTC (permalink / raw)
To: Drew Adams; +Cc: 9639, 'Stephen Berman'
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-01 14:41 ` Stefan Monnier
2011-10-01 17:04 ` martin rudalics
@ 2011-10-04 15:51 ` martin rudalics
1 sibling, 0 replies; 23+ messages in thread
From: martin rudalics @ 2011-10-04 15:51 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9639, Stephen Berman
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-04 15:51 ` martin rudalics
@ 2011-10-04 16:03 ` Drew Adams
2011-10-12 1:36 ` Christoph Scholtes
1 sibling, 0 replies; 23+ messages in thread
From: Drew Adams @ 2011-10-04 16:03 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 9639, 'Stephen Berman'
> > 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'.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-04 15:50 ` martin rudalics
@ 2011-10-04 17:45 ` Stefan Monnier
0 siblings, 0 replies; 23+ messages in thread
From: Stefan Monnier @ 2011-10-04 17:45 UTC (permalink / raw)
To: martin rudalics; +Cc: 9639, Stephen Berman
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
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
1 sibling, 1 reply; 23+ messages in thread
From: Christoph Scholtes @ 2011-10-12 1:36 UTC (permalink / raw)
To: martin rudalics; +Cc: 9639
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?
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions
2011-10-12 1:36 ` Christoph Scholtes
@ 2011-10-12 6:52 ` martin rudalics
0 siblings, 0 replies; 23+ messages in thread
From: martin rudalics @ 2011-10-12 6:52 UTC (permalink / raw)
To: Christoph Scholtes; +Cc: 9639
>> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#5357: 23.1; Attempt to drag rightmost scrollbar
2011-10-04 15:50 ` martin rudalics
@ 2011-10-15 10:26 ` martin rudalics
0 siblings, 0 replies; 23+ messages in thread
From: martin rudalics @ 2011-10-15 10:26 UTC (permalink / raw)
To: 5357-done
> I'm getting the title message when I grab the dividing line below a
> scrollbar that is /clearly/ not the rightmost one.
Should be fixed now on trunk.
Thanks, martin
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2011-10-15 10:26 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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).