* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
@ 2010-12-02 18:35 Drew Adams
2010-12-02 19:05 ` martin rudalics
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: Drew Adams @ 2010-12-02 18:35 UTC (permalink / raw)
To: 7533
This is another one of those annoyances that come from not testing with
non-nil `pop-up-frames' (just a guess).
emacs -Q
M-x set-variable RET pop-up-frames RET t RET
In Dired, flag several files for deletion, then hit `x'.
Answer `yes' or `no'.
When you hit `x' buffer *Deletions* pops up in its own frame, as it
should. When you type `yes' or `no', the frame should disappear. It
should be deleted. The last part of `dired-mark-pop-up' should be
something like this:
(save-window-excursion
(dired-pop-to-buffer bufname)
(apply function args)
(if (one-window-p) (delete-frame) (delete-window))) ; <===== NEW
If you don't think the `delete-window' is needed, then just use
(when (one-window-p) (delete-frame)).
The important thing, for me, is that the frame that was created just to
show the files that will be deleted (or whatever) goes away. It should
be only a _temporary_ frame because its only raison d'etre is as part of
the deletion etc. _dialog_.
[Martin will explain that a different test from `one-window-p' is more
appropriate. ;-) IIRC, he generally prefers something like this to
(one-window-p win): (eq win (frame-root-window (window-frame win))).]
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2010-11-30 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-02 18:35 bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' Drew Adams
@ 2010-12-02 19:05 ` martin rudalics
2010-12-02 19:22 ` Drew Adams
2011-01-18 22:14 ` bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' Drew Adams
2012-09-05 14:30 ` martin rudalics
2 siblings, 1 reply; 37+ messages in thread
From: martin rudalics @ 2010-12-02 19:05 UTC (permalink / raw)
To: Drew Adams; +Cc: 7533
> (save-window-excursion
> (dired-pop-to-buffer bufname)
> (apply function args)
> (if (one-window-p) (delete-frame) (delete-window))) ; <===== NEW
This would be funny when `pop-up-frames' is nil and a window gets reused
for showing the *Deletions* buffer. In particular if that window is the
only window on its frame ;-)
BTW the `save-window-excursion' is completely useless when you pop up a
new frame.
> The important thing, for me, is that the frame that was created just to
> show the files that will be deleted (or whatever) goes away. It should
> be only a _temporary_ frame because its only raison d'etre is as part of
> the deletion etc. _dialog_.
Here I have a simple function called `quit-restore-window' which does
exactly that.
> [Martin will explain that a different test from `one-window-p' is more
> appropriate. ;-) IIRC, he generally prefers something like this to
> (one-window-p win): (eq win (frame-root-window (window-frame win))).]
Because `one-window-p' calls `next-window' which I don't like. See the
recent discussion about `loop' endlessly cycling over windows.
martin
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-02 19:05 ` martin rudalics
@ 2010-12-02 19:22 ` Drew Adams
2010-12-03 8:17 ` martin rudalics
0 siblings, 1 reply; 37+ messages in thread
From: Drew Adams @ 2010-12-02 19:22 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
> This would be funny when `pop-up-frames' is nil and a window
> gets reused for showing the *Deletions* buffer. In particular
> if that window is the only window on its frame ;-)
Agreed. But what's the right test? It is _not_ `pop-up-frames' non-nil,
because users can do other things than that to cause a new frame to be created
for this dialog. What's needed is a test of whether a frame was newly created
for this dialog buffer. What's the code for that test?
> BTW the `save-window-excursion' is completely useless when
> you pop up a new frame.
Yes, I know. It was already there, and I left it. It seems benign in this case
AFAICT, but feel free to fix this as it really should be fixed.
The bug report is about the annoyance of not deleting a new frame that was
created (using whatever mechanism, including non-nil `pop-up-frames') for dialog
purposes. When the dialog is finished, such a new frame should disappear.
Users should not need to manually delete it.
How the bug gets fixed is up to you. I'm reporting the problem, not a
particular fix.
> > The important thing, for me, is that the frame that was
> > created just to show the files that will be deleted (or whatever)
> > goes away. It should be only a _temporary_ frame because its only
> > raison d'etre is as part of the deletion etc. _dialog_.
>
> Here I have a simple function called `quit-restore-window' which does
> exactly that.
If that does what's needed, fine; go for it. I have no objection.
> > [Martin will explain that a different test from
> > `one-window-p' is more appropriate. ;-) IIRC, he generally
> > prefers something like this to (one-window-p win):
> > (eq win (frame-root-window (window-frame win))).]
>
> Because `one-window-p' calls `next-window' which I don't
> like. See the recent discussion about `loop' endlessly cycling
> over windows.
As I said, "Martin will explain...". That's fine with me, as long as the bug
gets fixed.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-02 19:22 ` Drew Adams
@ 2010-12-03 8:17 ` martin rudalics
2010-12-03 16:22 ` Drew Adams
2010-12-03 20:27 ` Stefan Monnier
0 siblings, 2 replies; 37+ messages in thread
From: martin rudalics @ 2010-12-03 8:17 UTC (permalink / raw)
To: Drew Adams; +Cc: 7533
> Agreed. But what's the right test? It is _not_ `pop-up-frames' non-nil,
> because users can do other things than that to cause a new frame to be created
> for this dialog. What's needed is a test of whether a frame was newly created
> for this dialog buffer. What's the code for that test?
In the past, routines usually tested the settings of variables like
`pop-up-windows' or `pop-up-frames' to guess the expected behavior of
`display-buffer'. In most cases the guesses were correct. In a few
corner cases they failed and the example you cite above is one of them.
Here I have two things: A window parameter that tells for each window
whether the current buffer is the first buffer shown in it and a
separate global variable which gives some rudimentary information about
what the last `display-buffer' invocation did to find a suitable window.
The former exists independently of `display-buffer' so it also works for
a "manually" constructed or reused window or frame. The latter is
`display-buffer' specific and is mainly used for providing some feedback
about the change of the entire window configuration.
>> BTW the `save-window-excursion' is completely useless when
>> you pop up a new frame.
>
> Yes, I know. It was already there, and I left it. It seems benign in this case
> AFAICT, but feel free to fix this as it really should be fixed.
`save-window-excursion' is hardly ever benign. Whenever you find a
`display-buffer' wrapped in a `save-window-excursion' you can be 100%
sure that the code fails with popped up frames.
> The bug report is about the annoyance of not deleting a new frame that was
> created (using whatever mechanism, including non-nil `pop-up-frames') for dialog
> purposes. When the dialog is finished, such a new frame should disappear.
> Users should not need to manually delete it.
There's no formal definition of "dialog purpose" in Emacs and it's not
easy to do that in general. The major problem to address is whether and
how such a dialog can be disrupted by other activities and how to resume
it at a later time.
martin
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-03 8:17 ` martin rudalics
@ 2010-12-03 16:22 ` Drew Adams
2010-12-03 18:16 ` martin rudalics
2010-12-03 20:27 ` Stefan Monnier
1 sibling, 1 reply; 37+ messages in thread
From: Drew Adams @ 2010-12-03 16:22 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
> > But what's the right test? It is _not_ `pop-up-frames' non-nil,
> > because users can do other things than that to cause a new
> > frame to be created for this dialog. What's needed is a test of
> > whether a frame was newly created for this dialog buffer.
> > What's the code for that test?
>
> In the past, routines usually tested the settings of variables like
> `pop-up-windows' or `pop-up-frames' to guess the expected behavior of
> `display-buffer'. In most cases the guesses were correct. In a few
> corner cases they failed and the example you cite above is
> one of them.
What do you mean by "in the past"? In the past I saw no such problem as that
reported in this bug. (On the contrary - this annoyance was introduced in Emacs
23 - see below.)
> Here I have two things: A window parameter that tells for each window
> whether the current buffer is the first buffer shown in it and a
> separate global variable which gives some rudimentary
> information about what the last `display-buffer' invocation did to find a
> suitable window. The former exists independently of `display-buffer' so it
> also works for a "manually" constructed or reused window or frame. The latter
is
> `display-buffer' specific and is mainly used for providing some feedback
> about the change of the entire window configuration.
Please be specific. What window parameter? What global variable? Just what
are you trying to say? I can't even tell whether you're saying that you _have_
a solution or there _is no_ solution.
I repeat: "what's the right test?" What's the solution?
> > The bug report is about the annoyance of not deleting a
> > new frame that was created (using whatever mechanism, including non-nil
> > `pop-up-frames') for dialog purposes. When the dialog is finished,
> > such a new frame should disappear. Users should not need to
> > manually delete it.
>
> There's no formal definition of "dialog purpose" in Emacs and it's not
> easy to do that in general.
No one's asking for a "formal definition" of anything. The *Deletions* (or
whatever) window that lists the files that will be acted on if you type `yes' is
supplementary help for answering the prompt - nothing more. Its only reason for
being displayed ends as soon as you've answered the prompt.
I call that a dialog: ask a question and pop up some help for understanding the
question, then remove the displayed help when the question is answered. You can
call it anything you want. No "formal definition" is needed here, AFAICS.
If for some reason we cannot fix this, with all of the fancy artillary we have
in Emacs 24, then please at least regress to the sane behavior of older
releases.
Until Emacs 23, the help buffer here (e.g. *Marked Files*, *Deletions*,
whatever) was always popped up as a window, not as a frame, even if you had
non-nil `pop-up-frames'. And that window was (naturally) deleted when you type
yes/no. That behavior was fine (IMO). We've "progressed" to a PITA (introduced
in 23).
If you can obtain similar behavior for a popup frame, fine. If not, then please
restore the pre-23.2 design for such dialogs.
> The major problem to address is whether and
> how such a dialog can be disrupted by other activities and
> how to resume it at a later time.
If it's a major problem and you will end up complicating things further in order
to solve it, then I vote for a return to the simple behavior of the past. That
at least was not annoying and did not force users to manually close frames.
Thx.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-03 16:22 ` Drew Adams
@ 2010-12-03 18:16 ` martin rudalics
2010-12-03 18:33 ` Drew Adams
0 siblings, 1 reply; 37+ messages in thread
From: martin rudalics @ 2010-12-03 18:16 UTC (permalink / raw)
To: Drew Adams; +Cc: 7533
> What do you mean by "in the past"?
I wanted to express my hope that this will change in the future.
> Please be specific. What window parameter? What global variable? Just what
> are you trying to say? I can't even tell whether you're saying that you _have_
> a solution or there _is no_ solution.
If you're really interested have a look at the window-pub branch.
martin
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-03 18:16 ` martin rudalics
@ 2010-12-03 18:33 ` Drew Adams
2010-12-03 18:41 ` martin rudalics
0 siblings, 1 reply; 37+ messages in thread
From: Drew Adams @ 2010-12-03 18:33 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
> > Please be specific. What window parameter? What global
> > variable? Just what are you trying to say? I can't even
> > tell whether you're saying that you _have_ a solution or
> > there _is no_ solution.
>
> If you're really interested have a look at the window-pub branch.
Oh, so you were referring to something that is not (yet) in Emacs. That wasn't
clear from what you wrote.
What I'm interested in is a fix for this bug - in the next Emacs release. How
that's done I don't much care. Whether the fix comes from the "window-pub"
branch (whatever that is) or from somewhere else doesn't matter to me. It's the
user-visible behavior in the next Emacs release that I'm concerned about.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-03 18:33 ` Drew Adams
@ 2010-12-03 18:41 ` martin rudalics
2010-12-04 22:44 ` Chong Yidong
0 siblings, 1 reply; 37+ messages in thread
From: martin rudalics @ 2010-12-03 18:41 UTC (permalink / raw)
To: Drew Adams; +Cc: Chong Yidong, 7533
[-- Attachment #1: Type: text/plain, Size: 183 bytes --]
> What I'm interested in is a fix for this bug - in the next Emacs release.
Meanwhile we should restore the old behavior. Chong could
you please apply the attached patch.
martin
[-- Attachment #2: dired.el.diff --]
[-- Type: text/plain, Size: 823 bytes --]
*** /lisp/dired.el 2010-11-10 10:58:50.000000000 +0100
--- /lisp/dired.el 2010-12-03 19:31:02.234375000 +0100
***************
*** 2757,2763 ****
;; that's possible. (Bug#1806)
(split-window-vertically))
;; Otherwise, try to split WINDOW sensibly.
! (split-window-sensibly window)))))
(pop-to-buffer (get-buffer-create buf)))
;; If dired-shrink-to-fit is t, make its window fit its contents.
(when dired-shrink-to-fit
--- 2757,2764 ----
;; that's possible. (Bug#1806)
(split-window-vertically))
;; Otherwise, try to split WINDOW sensibly.
! (split-window-sensibly window))))
! pop-up-frames)
(pop-to-buffer (get-buffer-create buf)))
;; If dired-shrink-to-fit is t, make its window fit its contents.
(when dired-shrink-to-fit
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-03 8:17 ` martin rudalics
2010-12-03 16:22 ` Drew Adams
@ 2010-12-03 20:27 ` Stefan Monnier
2012-04-05 20:23 ` Drew Adams
1 sibling, 1 reply; 37+ messages in thread
From: Stefan Monnier @ 2010-12-03 20:27 UTC (permalink / raw)
To: martin rudalics; +Cc: 7533
> Here I have two things: A window parameter that tells for each window
> whether the current buffer is the first buffer shown in it and a
> separate global variable which gives some rudimentary information about
> what the last `display-buffer' invocation did to find a suitable window.
Indeed. We currently have display-buffer-mark-dedicated which goes in
this direction, but uses dedicatedness, which is not always
desired, apparently.
I think that adding a "buffer for which this window was created" window
parameter and always set it in display-buffer (regardless of
display-buffer-mark-dedicated) should allow correct handling of
such situations.
Stefan
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-03 18:41 ` martin rudalics
@ 2010-12-04 22:44 ` Chong Yidong
2010-12-16 18:27 ` Drew Adams
0 siblings, 1 reply; 37+ messages in thread
From: Chong Yidong @ 2010-12-04 22:44 UTC (permalink / raw)
To: martin rudalics; +Cc: 7533
martin rudalics <rudalics@gmx.at> writes:
> Meanwhile we should restore the old behavior. Chong could
> you please apply the attached patch.
Done.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-04 22:44 ` Chong Yidong
@ 2010-12-16 18:27 ` Drew Adams
2010-12-17 6:32 ` martin rudalics
0 siblings, 1 reply; 37+ messages in thread
From: Drew Adams @ 2010-12-16 18:27 UTC (permalink / raw)
To: 'Chong Yidong', 'martin rudalics'; +Cc: 7533
> > Meanwhile we should restore the old behavior. Chong could
> > you please apply the attached patch.
>
> Done.
FWIW, I still see the problem in the latest Windows binary:
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2010-12-13 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
Martin's patch fixes the problem only for non-nil `pop-up-frames'. (So strictly
speaking it responds to the Subject line of the bug. But it does not respond
fully to what I meant in the bug report.)
It does not fix the problem if the buffer (e.g. `*Marked Files*') is popped up
in a separate frame for some other reason, for example, via
`special-display-popup-frame'.
To reproduce:
emacs -Q
M-x set-variable RET
special-display-regexps RET
("[ ]?[*][^*]+[*]") RET
The bug needs to be fixed so that _whenever_ the buffer is shown in a separate
frame that frame gets deleted when the dialog is finished (e.g. when the Dired
command to copy/delete/... is finished).
If you think a full fix is too complicated for now for some reason, then at
least bind `q' in that popped up buffer so that `q' invokes `quit-window' (_not_
`View-quit'), which will delete the frame. IOW, as a workaround, at least give
it the behavior of *Buffer List*, where hitting `q' deletes the frame,
Obliging the user to hit `q' is not the real solution. It just provides a
temporary workaround and should be considered only if you conclude that
implementing a good solution is too hard for the moment.
Alternatively, restore the behavior in Emacs 22, where even if
`special-display-regexps' would normally cause the buffer to be displayed in a
separate frame it is not: it is popped up in a window of the current frame.
That overrides the user's setting, but at least it is not annoying.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-16 18:27 ` Drew Adams
@ 2010-12-17 6:32 ` martin rudalics
2010-12-17 15:32 ` Drew Adams
0 siblings, 1 reply; 37+ messages in thread
From: martin rudalics @ 2010-12-17 6:32 UTC (permalink / raw)
To: Drew Adams; +Cc: 'Chong Yidong', 7533
> M-x set-variable RET
> special-display-regexps RET
> ("[ ]?[*][^*]+[*]") RET
You shouldn't include the buffer in `special-display-regexps' in the
first place. Or, write a separate entry for such buffers.
> Alternatively, restore the behavior in Emacs 22, where even if
> `special-display-regexps' would normally cause the buffer to be displayed in a
> separate frame it is not: it is popped up in a window of the current frame.
Not necessarily: Try customizing `dired-shrink-to-fit' to nil.
martin
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-17 6:32 ` martin rudalics
@ 2010-12-17 15:32 ` Drew Adams
2010-12-17 16:12 ` martin rudalics
0 siblings, 1 reply; 37+ messages in thread
From: Drew Adams @ 2010-12-17 15:32 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 'Chong Yidong', 7533
> > M-x set-variable RET
> > special-display-regexps RET
> > ("[ ]?[*][^*]+[*]") RET
>
> You shouldn't include the buffer in `special-display-regexps' in the
> first place. Or, write a separate entry for such buffers.
That, my friend, is utterly ridiculous. Why not just tell me I shouldn't use
Emacs because it inconveniences you?
That's why we have option `special-display-regexps'. I _want_ such buffers to
be displayed in a separate frame whenever they are displayed.
And no, I do not want to be obliged to specify separately the name of each
buffer that Emacs might decide to use in a temporary dialog to provide info for
a dialog question.
That's just silly. That you would even bring it up, let alone proclaim it as a
rule ("you shouldn't") suggests bad faith.
The fact that when using `C', `x', etc. in Dired Emacs cannot tell that the
temporary display of a pop-up buffer is no longer needed after you hit RET, and
that Emacs does not remove such a frame like it removes a temporary pop-up
window, is a failing on Emacs's part.
The word "brain-dead" comes to mind (for Emacs, not for you). The world's best
editor was not built to act like this. From a user perspective this is a
regression since Emacs 22. Until release 23 Emacs was completely sane in this
respect - since Day One.
I've mentioned a couple of possible workarounds, the best of which is to just
return to the Emacs 22 behavior.
But ideally the code should be fixed to remove the frame when the Dired command
interaction is finished. There is no reason to show the buffer after the
operation is done. That buffer is a list of objects that _will_ be acted on
_if_ you confirm. After you confirm (or deny) its display has no raison d'etre.
Apparently you think that the proper fix of removing the frame is too hard to
implement for some reason. In that case I request that we return to the sane
behavior of Emacs 22.
> > Alternatively, restore the behavior in Emacs 22, where even if
> > `special-display-regexps' would normally cause the buffer
> > to be displayed in a separate frame it is not: it is popped
> > up in a window of the current frame.
>
> Not necessarily: Try customizing `dired-shrink-to-fit' to nil.
emacs -Q in Emacs 22 does exactly what I described: it pops up a window, not a
frame, and it removes the window when the user dialog is finished.
(And `dired-shrink-to-fit' should simply be removed. The only reason it ever
existed was for people on connections less than 1200 baud (300, 900). See
Richard's comment in the source code.)
Sounds like you are just _searching_ for reasons to defend this regression and
not fix this bug.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-17 15:32 ` Drew Adams
@ 2010-12-17 16:12 ` martin rudalics
2010-12-17 16:55 ` Drew Adams
0 siblings, 1 reply; 37+ messages in thread
From: martin rudalics @ 2010-12-17 16:12 UTC (permalink / raw)
To: Drew Adams; +Cc: 'Chong Yidong', 7533
> Apparently you think that the proper fix of removing the frame is too hard to
> implement for some reason. In that case I request that we return to the sane
> behavior of Emacs 22.
You can get the "sane" behavior if you don't include such buffers in
`special-display-regexps'.
> emacs -Q in Emacs 22 does exactly what I described: it pops up a window, not a
> frame, and it removes the window when the user dialog is finished.
emacs -Q in Emacs 23 does the same.
martin
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-17 16:12 ` martin rudalics
@ 2010-12-17 16:55 ` Drew Adams
2010-12-17 18:09 ` martin rudalics
2010-12-21 6:48 ` Chong Yidong
0 siblings, 2 replies; 37+ messages in thread
From: Drew Adams @ 2010-12-17 16:55 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 'Chong Yidong', 7533
> > Apparently you think that the proper fix of removing the
> > frame is too hard to implement for some reason. In that
> > case I request that we return to the sane behavior of Emacs 22.
>
> You can get the "sane" behavior if you don't include such buffers in
> `special-display-regexps'.
>
> > emacs -Q in Emacs 22 does exactly what I described: it
> > pops up a window, not a frame, and it removes the window
> > when the user dialog is finished.
>
> emacs -Q in Emacs 23 does the same.
Not at all. The context you omitted makes it clear that (a) you are reaching
for straws by bringing in `dired-shrink-to-fit' and (b) Emacs 22 does not suffer
the bug: it removes the temporary display when done.
You are showing nothing but bad faith. Why did you even make the partial fix,
wrt `pop-up-frames'? Why don't you just tell users they can get the "sane"
behavior by setting `pop-up-frames' to nil? This is a sorry state indeed.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-17 16:55 ` Drew Adams
@ 2010-12-17 18:09 ` martin rudalics
2010-12-17 18:40 ` Drew Adams
2010-12-21 6:48 ` Chong Yidong
1 sibling, 1 reply; 37+ messages in thread
From: martin rudalics @ 2010-12-17 18:09 UTC (permalink / raw)
To: Drew Adams; +Cc: 'Chong Yidong', 7533
> You are showing nothing but bad faith. Why did you even make the partial fix,
> wrt `pop-up-frames'? Why don't you just tell users they can get the "sane"
> behavior by setting `pop-up-frames' to nil? This is a sorry state indeed.
`pop-up-frames' expresses a general preference so I asked Chong to make
that change. `special-display-regexps' expresses a special preference.
But if nobody objects we can bind things like `special-display-regexps'
and `special-display-buffer-names' to nil here too.
martin
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-17 18:09 ` martin rudalics
@ 2010-12-17 18:40 ` Drew Adams
0 siblings, 0 replies; 37+ messages in thread
From: Drew Adams @ 2010-12-17 18:40 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 'Chong Yidong', 7533
> `pop-up-frames' expresses a general preference so I asked
> Chong to make that change. `special-display-regexps'
> expresses a special preference. But if nobody objects we
> can bind things like `special-display-regexps'
> and `special-display-buffer-names' to nil here too.
That's better than nothing, IMO. It recognizes that this buffer display,
whether in a frame or window, is only temporary, for the duration of the
confirmation interaction: there is no reason to show the buffer after the
command is done.
However, the right fix is to (a) respect a user's preference to show such
buffers in a special frame and then (b) delete the frame.
It is especially not very kosher to override `special-display-buffer-names',
because that option can let users specify not only a buffer name but a specific
function to display it.
IOW, the most important thing in this context is to remove the buffer display
when done. But it is also important to do what the user wants.
So showing such a buffer in a window instead of a frame should be seen as only a
temporary workaround, since it violates a user preference of using a frame. It
is a temporary expedient, to obviate the annoyance of not properly handling a
frame in this context.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-17 16:55 ` Drew Adams
2010-12-17 18:09 ` martin rudalics
@ 2010-12-21 6:48 ` Chong Yidong
1 sibling, 0 replies; 37+ messages in thread
From: Chong Yidong @ 2010-12-21 6:48 UTC (permalink / raw)
To: Drew Adams; +Cc: 7533
"Drew Adams" <drew.adams@oracle.com> writes:
> You are showing nothing but bad faith.
That's an incredibly rude and arrogant way to treat a volunteer
developer.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-02 18:35 bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' Drew Adams
2010-12-02 19:05 ` martin rudalics
@ 2011-01-18 22:14 ` Drew Adams
2012-09-05 14:30 ` martin rudalics
2 siblings, 0 replies; 37+ messages in thread
From: Drew Adams @ 2011-01-18 22:14 UTC (permalink / raw)
To: rudalics; +Cc: cyd, 7533
> From: martin rudalics Sent: Friday, December 17, 2010 10:09 AM
>
> if nobody objects we can bind things like `special-display-regexps'
> and `special-display-buffer-names' to nil here too.
Please do. That would presumably restore the behavior of Emacs 22: pop-up
window (deleted afterward), not frame (left undeleted).
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-03 20:27 ` Stefan Monnier
@ 2012-04-05 20:23 ` Drew Adams
2012-04-06 14:02 ` martin rudalics
0 siblings, 1 reply; 37+ messages in thread
From: Drew Adams @ 2012-04-05 20:23 UTC (permalink / raw)
To: 'Stefan Monnier', 'martin rudalics'; +Cc: 7533
> From: Stefan Monnier Sent: Friday, December 03, 2010 12:27 PM
> > Here I have two things: A window parameter that tells for
> > each window whether the current buffer is the first buffer
> > shown in it and a separate global variable which gives some
> > rudimentary information about what the last `display-buffer'
> > invocation did to find a suitable window.
>
> Indeed. We currently have display-buffer-mark-dedicated which goes in
> this direction, but uses dedicatedness, which is not always
> desired, apparently.
>
> I think that adding a "buffer for which this window was
> created" window parameter and always set it in display-buffer
> (regardless of display-buffer-mark-dedicated) should allow
> correct handling of such situations.
This regression is still not fixed. There was a lot of dancing around and
singing about new ways of handling buffer display and windows (vs old-fashioned
`pop-up-frames' etc.). But the new ways were added to Emacs and this regression
still remains.
emacs -Q
(setq special-display-regexps '("[ ]?[*][^*]+[*]"))
(setq pop-up-frame t)
C-x d whatever-dir
Mark 4 files for deletion. Hit `x'. Answer `yes'.
The *Deletions* frame remains displayed.
At the beginning of this thread I offered some code that at least handles this
case fine, AFAICT. Actually, I forgot a prog1. Here it is again... The only
difference from what is in Emacs is the last two lines, which delete the frame
when done. That's all I'm asking for: please delete the frame that you pop up.
(defun dired-mark-pop-up (bufname op-symbol files function &rest args)
"..."
(or bufname (setq bufname " *Marked Files*"))
(if (or (eq dired-no-confirm t)
(memq op-symbol dired-no-confirm)
;; If FILES defaulted to the current line's file.
(= (length files) 1))
(apply function args)
(with-current-buffer (get-buffer-create bufname)
(erase-buffer)
;; Handle (t FILE) just like (FILE), here.
;; That value is used (only in some cases), to mean just one
;; file that was marked, rather than the current line file.
(dired-format-columns-of-files
(if (eq (car files) t) (cdr files) files))
(remove-text-properties (point-min) (point-max)
'(mouse-face nil help-echo nil)))
(save-window-excursion
(dired-pop-to-buffer bufname)
(prog1 (apply function args)
(if (one-window-p) (delete-frame) (delete-window))))))
Yes, it is no doubt true that `save-window-excursion' is inappropriate when used
with code displaying a buffer, as Martin pointed. Yes, there might be other
things inappropriate or inelegant here. But it works for the use case of the
bug report at least, and Emacs 24 -Q does not work for that case.
Again, I do not really care how this bug is fixed. But please fix it.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-04-05 20:23 ` Drew Adams
@ 2012-04-06 14:02 ` martin rudalics
2012-04-06 14:44 ` Drew Adams
0 siblings, 1 reply; 37+ messages in thread
From: martin rudalics @ 2012-04-06 14:02 UTC (permalink / raw)
To: Drew Adams; +Cc: 7533
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
> emacs -Q
>
> (setq special-display-regexps '("[ ]?[*][^*]+[*]"))
> (setq pop-up-frame t)
I suppose you mean
(setq pop-up-frames t)
but apparently this variable is no more supported by `display-buffer'
(I'm not sure whether that's by design).
> C-x d whatever-dir
>
> Mark 4 files for deletion. Hit `x'. Answer `yes'.
>
> The *Deletions* frame remains displayed.
Would the attached patch fix it?
This is NOT a generic fix - it might fail miserably if the buffer in
question is shown in two windows simultaneously. Apparently this is no
great issue in the case at hand since `dired-pop-to-buffer' already
calls `get-buffer-window'. I earlier provided a variable called
`display-buffer-window' for this and related issues but Stefan didn't
like it.
martin
[-- Attachment #2: dired.diff --]
[-- Type: text/plain, Size: 1919 bytes --]
bzr diff
=== modified file 'lisp/dired.el'
--- lisp/dired.el 2012-04-01 02:44:24 +0000
+++ lisp/dired.el 2012-04-06 13:35:09 +0000
@@ -2950,8 +2950,7 @@
;; that's possible. (Bug#1806)
(split-window-below))
;; Otherwise, try to split WINDOW sensibly.
- (split-window-sensibly window))))
- pop-up-frames)
+ (split-window-sensibly window)))))
(pop-to-buffer (get-buffer-create buf)))
;; If dired-shrink-to-fit is t, make its window fit its contents.
(when dired-shrink-to-fit
@@ -2993,17 +2992,21 @@
;; If FILES defaulted to the current line's file.
(= (length files) 1))
(apply function args)
- (with-current-buffer (get-buffer-create bufname)
- (erase-buffer)
- ;; Handle (t FILE) just like (FILE), here.
- ;; That value is used (only in some cases), to mean
- ;; just one file that was marked, rather than the current line file.
- (dired-format-columns-of-files (if (eq (car files) t) (cdr files) files))
- (remove-text-properties (point-min) (point-max)
- '(mouse-face nil help-echo nil)))
- (save-window-excursion
- (dired-pop-to-buffer bufname)
- (apply function args))))
+ (let ((buffer (get-buffer-create bufname)))
+ (with-current-buffer buffer
+ (erase-buffer)
+ ;; Handle (t FILE) just like (FILE), here.
+ ;; That value is used (only in some cases), to mean
+ ;; just one file that was marked, rather than the current line file.
+ (dired-format-columns-of-files (if (eq (car files) t) (cdr files) files))
+ (remove-text-properties (point-min) (point-max)
+ '(mouse-face nil help-echo nil))
+ (dired-pop-to-buffer buffer)
+ (let ((window (get-buffer-window buffer)))
+ (prog1
+ (apply function args)
+ (when (and window (eq (window-buffer window) buffer))
+ (quit-window nil window))))))))
(defun dired-format-columns-of-files (files)
(let ((beg (point)))
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-04-06 14:02 ` martin rudalics
@ 2012-04-06 14:44 ` Drew Adams
2012-04-06 14:53 ` martin rudalics
0 siblings, 1 reply; 37+ messages in thread
From: Drew Adams @ 2012-04-06 14:44 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
> > emacs -Q
> > (setq special-display-regexps '("[ ]?[*][^*]+[*]"))
> > (setq pop-up-frame t)
>
> I suppose you mean (setq pop-up-frames t)
Yes.
> but apparently this variable is no more supported by `display-buffer'
> (I'm not sure whether that's by design).
I don't know what you mean by that. Dunno whether it is supported by
`display-buffer, but I do still use `pop-up-frames' and it works fine in general
(apart from this bug, AFAIK). And I thought you took care to ensure that it
did, for Emacs 24.
> > C-x d whatever-dir
> > Mark 4 files for deletion. Hit `x'. Answer `yes'.
> > The *Deletions* frame remains displayed.
>
> Would the attached patch fix it?
For my own complete setup, yes. But that's no doubt because I take other
measures elsewhere.
For the recipe I gave, however (see above), no. The separate `*Deletions*'
frame popped up just becomes iconified. It is still available as a frame (and
as a buffer). It is still in the list of frames, and it is thus shown in the MS
Windows task bar.
And on Windows at least, iconification is quite distracting. The frame does not
simply disappear (and simultaneously get added to the task bar). The frame
zooms down to the task bar in an animated fashion. Quite annoying.
There is no need for either the frame or the window - or the buffer for that
matter, after the deletions are done (or the copies or whatever
`dired-mark-pop-up' was used for).
By Occam's razor, no need means Emacs should not keep these things around
vestigially - especially not so that users encounter them.
> This is NOT a generic fix - it might fail miserably if the buffer in
> question is shown in two windows simultaneously. Apparently
> this is no great issue in the case at hand since
> `dired-pop-to-buffer' already calls `get-buffer-window'.
> I earlier provided a variable called `display-buffer-window'
> for this and related issues but Stefan didn't like it.
FWIW, the fix I sent still works. Perhaps it can be improved upon to satisfy
whatever other needs you see that it does not quite satisfy?
One way or another, the regression needs to be fixed. Things were OK back in
Emacs 22. There should be no reason why we cannot make them OK again in this
regard.
In Emacs 22 the buffer was not shown in a separate frame, disrespecting
`special-display-regexps'. I prefer (slightly) that the latter be respected, so
that the buffer is shown in a separate frame. But only if the frame, like a
pop-up window, is completely removed when done.
Given the choice between your fix and the Emacs 22 behavior, I vastly prefer the
latter: no distraction, simple, over and done with, never see `*Deletions*' or
whatever again.
Thanks for trying to fix this, Martin. I hope we can find a solution that is
satisfactory. The fix I sent is good enough for me, but I understand if it is
not good enough for you.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-04-06 14:44 ` Drew Adams
@ 2012-04-06 14:53 ` martin rudalics
2012-04-06 15:34 ` Drew Adams
0 siblings, 1 reply; 37+ messages in thread
From: martin rudalics @ 2012-04-06 14:53 UTC (permalink / raw)
To: Drew Adams; +Cc: 7533
>> but apparently this variable is no more supported by `display-buffer'
>> (I'm not sure whether that's by design).
>
> I don't know what you mean by that. Dunno whether it is supported by
> `display-buffer, but I do still use `pop-up-frames' and it works fine in general
> (apart from this bug, AFAIK). And I thought you took care to ensure that it
> did, for Emacs 24.
It was disabled by `dired-pop-to-buffer'. Already fixed in my patch.
>> Would the attached patch fix it?
>
> For my own complete setup, yes. But that's no doubt because I take other
> measures elsewhere.
>
> For the recipe I gave, however (see above), no. The separate `*Deletions*'
> frame popped up just becomes iconified. It is still available as a frame (and
> as a buffer). It is still in the list of frames, and it is thus shown in the MS
> Windows task bar.
Have you set `frame-auto-hide-function' to `delete-frame'?
> In Emacs 22 the buffer was not shown in a separate frame, disrespecting
> `special-display-regexps'. I prefer (slightly) that the latter be respected, so
> that the buffer is shown in a separate frame. But only if the frame, like a
> pop-up window, is completely removed when done.
The current handling of `special-display-regexps' seems to override the
way Emacs 22 behaved in this regard.
martin
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-04-06 14:53 ` martin rudalics
@ 2012-04-06 15:34 ` Drew Adams
2012-04-06 15:47 ` martin rudalics
0 siblings, 1 reply; 37+ messages in thread
From: Drew Adams @ 2012-04-06 15:34 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
> It was disabled by `dired-pop-to-buffer'. Already fixed in my patch.
I see.
> >> Would the attached patch fix it?
> >
> > For my own complete setup, yes. But that's no doubt
> > because I take other measures elsewhere.
> >
> > For the recipe I gave, however (see above), no. The
> > separate `*Deletions*' frame popped up just becomes
> > iconified. It is still available as a frame (and
> > as a buffer). It is still in the list of frames, and
> > it is thus shown in the MS Windows task bar.
>
> Have you set `frame-auto-hide-function' to `delete-frame'?
In my own setup, yes. No doubt that is why I don't have a problem with it.
But that's not a reason that users with just the two settings I mentioned should
see this problem.
Whatever the cause (and various user configs can lead to this), if the buffer is
displayed in a separate frame there is _no_ reason, ever, to keep this frame (or
its window or its buffer). Occam says delete it - don't just "hide" it.
This is part of the logic of this particular user interaction. And yes, I
realize that there is no general definition of such a "dialog" interaction in
Emacs (yet). But in handling this particular interaction it is clear to the
code and its designers that the frame+window+buffer have no further use.
Knowing that, the code should DTRT. Iconifying here makes no sense, even if a
user might choose iconifying in general as his preference for
`frame-auto-hide-function'. That option is about hiding a frame. There is no
reason to hide this frame. There is no reason to keep this frame (or its window
or buffer).
That's the point. It is not about `frame-auto-hide-function', which is a user
preference about hiding frames. It is about the logic of this particular user
interaction and the raison d'etre for this buffer/window/frame. When they no
longer have any reason for existing they should be deleted - regardless of the
value of `frame-auto-hide-function'.
> The current handling of `special-display-regexps' seems to
> override the way Emacs 22 behaved in this regard.
It is good in general that `special-display-regexps' be respected.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-04-06 15:34 ` Drew Adams
@ 2012-04-06 15:47 ` martin rudalics
2012-04-06 16:10 ` Drew Adams
0 siblings, 1 reply; 37+ messages in thread
From: martin rudalics @ 2012-04-06 15:47 UTC (permalink / raw)
To: Drew Adams; +Cc: 7533
>> Have you set `frame-auto-hide-function' to `delete-frame'?
>
> In my own setup, yes. No doubt that is why I don't have a problem with it.
So it worked without my patch?
martin
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-04-06 15:47 ` martin rudalics
@ 2012-04-06 16:10 ` Drew Adams
2012-04-06 16:56 ` martin rudalics
0 siblings, 1 reply; 37+ messages in thread
From: Drew Adams @ 2012-04-06 16:10 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
> >> Have you set `frame-auto-hide-function' to `delete-frame'?
> >
> > In my own setup, yes. No doubt that is why I don't have a
> > problem with it.
>
> So it worked without my patch?
Sorry. I forgot that my setup includes the fix I proposed, as well as
`delete-frame' as the value of `frame-auto-hide-function'.
Without my fix and without your patch, just having `delete-frame' as the value
of `frame-auto-hide-function' was not adequate. Same behavior as
`iconify-frame'.
Without my fix and with your patch, even having `iconify-frame' as the value of
`frame-auto-hide-function' was adequate. So I probably have some other code
that takes care of the iconify/delete thing somewhere.
In sum, your patch (or mine), plus `delete-frame' as the value of
`frame-auto-hide-function', is adequate. Without one of those patches, no value
of `frame-auto-hide-function' makes a difference.
For emacs -Q:
Without my fix and with your patch the frame is iconified, without changing
`frame-auto-hide-function'.
Without my fix and with your patch the frame is deleted, if
`frame-auto-hide-function' is `delete-frame'.
My point was that users should not have to customize this option just to fix
this regression. It is reasonable for a user to prefer iconifying for frames
that s?he wants to keep, but still, naturally, want this frame to be deleted, as
it has no reason for being anymore.
If you were not averse to binding a user option for a local use, perhaps you
could just bind `frame-auto-hide-function' to `delete-frame' for the duration of
the command. That should DTRT, and such a temporary binding should not bother
anyone (IMHO).
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-04-06 16:10 ` Drew Adams
@ 2012-04-06 16:56 ` martin rudalics
2012-04-06 17:08 ` Drew Adams
0 siblings, 1 reply; 37+ messages in thread
From: martin rudalics @ 2012-04-06 16:56 UTC (permalink / raw)
To: Drew Adams; +Cc: 7533
> In sum, your patch (or mine), plus `delete-frame' as the value of
> `frame-auto-hide-function', is adequate.
IIUC your patch works regardless of the value of
`frame-auto-hide-function'. The problem of your patch is that in
(if (one-window-p) (delete-frame) (delete-window))
the window for showing the buffer may have been _reused_ in which case
deleting is certainly the wrong solution.
> For emacs -Q:
>
> Without my fix and with your patch the frame is iconified, without changing
> `frame-auto-hide-function'.
>
> Without my fix and with your patch the frame is deleted, if
> `frame-auto-hide-function' is `delete-frame'.
That's what this option has been meant for. I can't judge what it
should default to because I hardly ever use multiple frames and never
use `dired'.
> My point was that users should not have to customize this option just to fix
> this regression. It is reasonable for a user to prefer iconifying for frames
> that s?he wants to keep, but still, naturally, want this frame to be deleted, as
> it has no reason for being anymore.
We can consider adding a third value for `frame-auto-hide-function'.
> If you were not averse to binding a user option for a local use, perhaps you
> could just bind `frame-auto-hide-function' to `delete-frame' for the duration of
> the command. That should DTRT, and such a temporary binding should not bother
> anyone (IMHO).
If we decide that deleting the frame is the correct solution in this
particular case, the most simple option is to call `quit-window' with
both arguments t, thus killing the buffer as well.
martin
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-04-06 16:56 ` martin rudalics
@ 2012-04-06 17:08 ` Drew Adams
2012-04-18 14:32 ` Drew Adams
0 siblings, 1 reply; 37+ messages in thread
From: Drew Adams @ 2012-04-06 17:08 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
> > For emacs -Q:
> >
> > Without my fix and with your patch the frame is iconified,
> > without changing `frame-auto-hide-function'.
> >
> > Without my fix and with your patch the frame is deleted, if
> > `frame-auto-hide-function' is `delete-frame'.
>
> That's what this option has been meant for.
Yes, in the general case. It is a general user option. IMO, it does not apply
here, that is, it should not govern the behavior here.
> > I can't judge what it should default to because I hardly ever
> > use multiple frames and never use `dired'.
We've been around the default-value barn several times already. Stefan wants
iconifying as the default. I'm happy if users can at least customize it to get
deletion.
> > My point was that users should not have to customize this
> > option just to fix this regression. It is reasonable for
> > a user to prefer iconifying for frames that s?he wants to
> > keep, but still, naturally, want this frame to be deleted, as
> > it has no reason for being anymore.
>
> We can consider adding a third value for `frame-auto-hide-function'.
I think that's blowing things out of proportion. There is no need for a user
option for this. A user option is for general behavior. Unless, that is, you
can characterize such behavior as a general class that is recognizable. But I
thought that was the problem: no "dialog" thingy exists.
IMO, the proper fix here is specific to this command. And to any others that we
run into that pop up a frame only temporarily, for the duration of some well
defined (recognizable) user interaction.
> > If you were not averse to binding a user option for a
> > local use, perhaps you could just bind `frame-auto-hide-function'
> > to `delete-frame' for the duration of the command. That should
> > DTRT, and such a temporary binding should not bother
> > anyone (IMHO).
>
> If we decide that deleting the frame is the correct solution in this
> particular case, the most simple option is to call `quit-window' with
> both arguments t, thus killing the buffer as well.
Sounds good to me, IIUC. Does anyone claim that deleting the frame (& window &
buffer) is not the correct solution in this situation?
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-04-06 17:08 ` Drew Adams
@ 2012-04-18 14:32 ` Drew Adams
2012-05-25 20:52 ` Drew Adams
0 siblings, 1 reply; 37+ messages in thread
From: Drew Adams @ 2012-04-18 14:32 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
ping
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-04-18 14:32 ` Drew Adams
@ 2012-05-25 20:52 ` Drew Adams
2012-05-26 17:55 ` bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' [PATCH] Drew Adams
0 siblings, 1 reply; 37+ messages in thread
From: Drew Adams @ 2012-05-25 20:52 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
ping again.
This is a regression. It has a simple fix.
Can this please be fixed?
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' [PATCH]
2012-05-25 20:52 ` Drew Adams
@ 2012-05-26 17:55 ` Drew Adams
2012-05-27 13:21 ` martin rudalics
0 siblings, 1 reply; 37+ messages in thread
From: Drew Adams @ 2012-05-26 17:55 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]
Martin wrote:
> IIUC your patch works regardless of the value of
> `frame-auto-hide-function'. The problem of your patch is that in
> (if (one-window-p) (delete-frame) (delete-window))
> the window for showing the buffer may have been _reused_ in which case
> deleting is certainly the wrong solution.
I do not understand how/why that window would or should be reused.
Especially between the time it becomes displayed and the end of the calling
function. The window is only for the user interaction of confirming (or not)
the operation on the marked files.
The existing code seems to reflect this aim in that it uses
`save-window-excursion'. What is still missing is (a) deletion of the window or
frame (if `one-window-p') and (b) burial of the buffer. And this should happen
always, regardless of what the user does, including `C-g'.
If the buffer is not shown in a separate frame then the `save-window-excursion'
alone seems to remove/hide the window - great. And that is why more people are
not complaining about this regression, IMO.
But if the buffer is shown in a separate frame (e.g. due to
`special-buffer-regexps') then `save-window-excursion' is simply not sufficient.
The frame remains displayed after the user interaction, regardless of what the
user does during the interaction (including `C-g').
Attached is a patch against the latest source code. AFAIK it DTRT. Can anyone
point to a reasonable situation where it does not DTRT - IOW, where what it does
is inappropriate? If not, can this please be installed for Emacs 24.1, to
eliminate this regression? Thx.
Here is a change-log entry for the patch:
2012-05-26 Drew Adams <drew.adams@oracle.com>
* dired.el (dired-mark-pop-up):
Delete the marked-files window/frame and bury its buffer.
[-- Attachment #2: dired-2012-05-26.patch --]
[-- Type: application/octet-stream, Size: 2556 bytes --]
diff -c dired.el dired-patched-2012-05-26.el
*** dired.el Sat May 26 09:48:52 2012
--- dired-patched-2012-05-26.el Sat May 26 10:43:26 2012
***************
*** 2988,3009 ****
in the case of one marked file, to distinguish that from using
just the current file."
(or bufname (setq bufname " *Marked Files*"))
! (if (or (eq dired-no-confirm t)
! (memq op-symbol dired-no-confirm)
! ;; If FILES defaulted to the current line's file.
! (= (length files) 1))
! (apply function args)
! (with-current-buffer (get-buffer-create bufname)
! (erase-buffer)
! ;; Handle (t FILE) just like (FILE), here.
! ;; That value is used (only in some cases), to mean
! ;; just one file that was marked, rather than the current line file.
! (dired-format-columns-of-files (if (eq (car files) t) (cdr files) files))
! (remove-text-properties (point-min) (point-max)
! '(mouse-face nil help-echo nil)))
! (save-window-excursion
! (dired-pop-to-buffer bufname)
! (apply function args))))
(defun dired-format-columns-of-files (files)
(let ((beg (point)))
--- 2988,3016 ----
in the case of one marked file, to distinguish that from using
just the current file."
(or bufname (setq bufname " *Marked Files*"))
! (let (result)
! (if (or (eq dired-no-confirm t)
! (memq op-symbol dired-no-confirm)
! ;; If FILES defaulted to the current line's file.
! (= (length files) 1))
! (setq result (apply function args))
! (with-current-buffer (get-buffer-create bufname)
! (erase-buffer)
! ;; Handle (t FILE) just like (FILE), here.
! ;; That value is used (only in some cases), to mean
! ;; just one file that was marked, rather than the current line file.
! (dired-format-columns-of-files (if (eq (car files) t) (cdr files) files))
! (remove-text-properties (point-min) (point-max)
! '(mouse-face nil help-echo nil)))
! (unwind-protect
! (save-window-excursion
! (dired-pop-to-buffer bufname)
! (setq result (apply function args)))
! (ignore-errors
! (select-window (get-buffer-window bufname 0))
! (if (one-window-p) (delete-frame) (delete-window)))
! (bury-buffer bufname)))
! result))
(defun dired-format-columns-of-files (files)
(let ((beg (point)))
Diff finished. Sat May 26 10:48:28 2012
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' [PATCH]
2012-05-26 17:55 ` bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' [PATCH] Drew Adams
@ 2012-05-27 13:21 ` martin rudalics
2012-05-27 14:33 ` Drew Adams
0 siblings, 1 reply; 37+ messages in thread
From: martin rudalics @ 2012-05-27 13:21 UTC (permalink / raw)
To: Drew Adams; +Cc: 7533
>> IIUC your patch works regardless of the value of
>> `frame-auto-hide-function'. The problem of your patch is that in
>> (if (one-window-p) (delete-frame) (delete-window))
>> the window for showing the buffer may have been _reused_ in which case
>> deleting is certainly the wrong solution.
>
> I do not understand how/why that window would or should be reused.
When a user sets both `pop-up-frames' and `pop-up-windows' to nil,
usually a window gets reused. If this is the only window on its frame
and there are no other frames, the `delete-frame' call causes an error
because it's within the scope of the `save-window-excursion'.
> Especially between the time it becomes displayed and the end of the calling
> function. The window is only for the user interaction of confirming (or not)
> the operation on the marked files.
>
> The existing code seems to reflect this aim in that it uses
> `save-window-excursion'. What is still missing is (a) deletion of the window or
> frame (if `one-window-p') and (b) burial of the buffer. And this should happen
> always, regardless of what the user does, including `C-g'.
If the window was reused, the previous buffer should be shown. In
practice, this is handled by the `save-window-excursion' unless a window
on another frame gets reused.
> If the buffer is not shown in a separate frame then the `save-window-excursion'
> alone seems to remove/hide the window - great. And that is why more people are
> not complaining about this regression, IMO.
>
> But if the buffer is shown in a separate frame (e.g. due to
> `special-buffer-regexps') then `save-window-excursion' is simply not sufficient.
> The frame remains displayed after the user interaction, regardless of what the
> user does during the interaction (including `C-g').
>
> Attached is a patch against the latest source code. AFAIK it DTRT. Can anyone
> point to a reasonable situation where it does not DTRT - IOW, where what it does
> is inappropriate? If not, can this please be installed for Emacs 24.1, to
> eliminate this regression? Thx.
Your new patch is better since it moves the frame deletion out of the
scope of the window excursion. It's still not OK when a window on
another frame gets reused but I think that use case can be ignored at
the moment (it's neither provided by any of the stock buffer display
functions nor is it handled by the present code anyway).
martin
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' [PATCH]
2012-05-27 13:21 ` martin rudalics
@ 2012-05-27 14:33 ` Drew Adams
0 siblings, 0 replies; 37+ messages in thread
From: Drew Adams @ 2012-05-27 14:33 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
Thanks for the explanation (snipped).
> > Attached is a patch against the latest source code. AFAIK
> > it DTRT. Can anyone point to a reasonable situation where
> > it does not DTRT - IOW, where what it does is inappropriate?
> > If not, can this please be installed for Emacs 24.1, to
> > eliminate this regression? Thx.
>
> Your new patch is better since it moves the frame deletion out of the
> scope of the window excursion. It's still not OK when a window on
> another frame gets reused but I think that use case can be ignored at
> the moment (it's neither provided by any of the stock buffer display
> functions nor is it handled by the present code anyway).
Great. I hope someone will please install it (for 24.1?), while we look for
something even better. Thx.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2010-12-02 18:35 bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' Drew Adams
2010-12-02 19:05 ` martin rudalics
2011-01-18 22:14 ` bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' Drew Adams
@ 2012-09-05 14:30 ` martin rudalics
2012-09-05 14:33 ` Drew Adams
2 siblings, 1 reply; 37+ messages in thread
From: martin rudalics @ 2012-09-05 14:30 UTC (permalink / raw)
To: Drew Adams; +Cc: 7533
> This is another one of those annoyances that come from not testing with
> non-nil `pop-up-frames' (just a guess).
>
> emacs -Q
>
> M-x set-variable RET pop-up-frames RET t RET
>
> In Dired, flag several files for deletion, then hit `x'.
> Answer `yes' or `no'.
[...]
> The important thing, for me, is that the frame that was created just to
> show the files that will be deleted (or whatever) goes away. It should
> be only a _temporary_ frame because its only raison d'etre is as part of
> the deletion etc. _dialog_.
This should have been fixed in revision 109863 on Emacs trunk.
Please check as soon as you get new binaries.
Thanks, martin
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-09-05 14:30 ` martin rudalics
@ 2012-09-05 14:33 ` Drew Adams
2012-10-03 9:11 ` martin rudalics
2012-10-03 15:52 ` Drew Adams
0 siblings, 2 replies; 37+ messages in thread
From: Drew Adams @ 2012-09-05 14:33 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
> This should have been fixed in revision 109863 on Emacs trunk.
> Please check as soon as you get new binaries.
>
> Thanks, martin
Excellent; will do. Thanks, Martin.
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-09-05 14:33 ` Drew Adams
@ 2012-10-03 9:11 ` martin rudalics
2012-10-03 15:52 ` Drew Adams
1 sibling, 0 replies; 37+ messages in thread
From: martin rudalics @ 2012-10-03 9:11 UTC (permalink / raw)
To: 7533-done
>> This should have been fixed in revision 109863 on Emacs trunk.
Bug closed.
martin
^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
2012-09-05 14:33 ` Drew Adams
2012-10-03 9:11 ` martin rudalics
@ 2012-10-03 15:52 ` Drew Adams
1 sibling, 0 replies; 37+ messages in thread
From: Drew Adams @ 2012-10-03 15:52 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 7533
> Sent: Wednesday, September 05, 2012 7:34 AM
>
> > This should have been fixed in revision 109863 on Emacs trunk.
> > Please check as soon as you get new binaries.
> >
> > Thanks, martin
>
> Excellent; will do. Thanks, Martin.
Finally got a Windows binary that I could check this with.
There was a lot in this thread. Not sure that everything discussed was
addressed, but the latest emacs -Q recipe I posted in the thread works OK now.
Thx.
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2012-10-03 15:52 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-02 18:35 bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' Drew Adams
2010-12-02 19:05 ` martin rudalics
2010-12-02 19:22 ` Drew Adams
2010-12-03 8:17 ` martin rudalics
2010-12-03 16:22 ` Drew Adams
2010-12-03 18:16 ` martin rudalics
2010-12-03 18:33 ` Drew Adams
2010-12-03 18:41 ` martin rudalics
2010-12-04 22:44 ` Chong Yidong
2010-12-16 18:27 ` Drew Adams
2010-12-17 6:32 ` martin rudalics
2010-12-17 15:32 ` Drew Adams
2010-12-17 16:12 ` martin rudalics
2010-12-17 16:55 ` Drew Adams
2010-12-17 18:09 ` martin rudalics
2010-12-17 18:40 ` Drew Adams
2010-12-21 6:48 ` Chong Yidong
2010-12-03 20:27 ` Stefan Monnier
2012-04-05 20:23 ` Drew Adams
2012-04-06 14:02 ` martin rudalics
2012-04-06 14:44 ` Drew Adams
2012-04-06 14:53 ` martin rudalics
2012-04-06 15:34 ` Drew Adams
2012-04-06 15:47 ` martin rudalics
2012-04-06 16:10 ` Drew Adams
2012-04-06 16:56 ` martin rudalics
2012-04-06 17:08 ` Drew Adams
2012-04-18 14:32 ` Drew Adams
2012-05-25 20:52 ` Drew Adams
2012-05-26 17:55 ` bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' [PATCH] Drew Adams
2012-05-27 13:21 ` martin rudalics
2012-05-27 14:33 ` Drew Adams
2011-01-18 22:14 ` bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' Drew Adams
2012-09-05 14:30 ` martin rudalics
2012-09-05 14:33 ` Drew Adams
2012-10-03 9:11 ` martin rudalics
2012-10-03 15:52 ` Drew Adams
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).