[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-
From: |
Drew Adams |
Subject: |
bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' |
Date: |
Fri, 6 Apr 2012 10:08:48 -0700 |
> > 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?
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', Drew Adams, 2012/04/05
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', martin rudalics, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', Drew Adams, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', martin rudalics, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', Drew Adams, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', martin rudalics, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', Drew Adams, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', martin rudalics, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames',
Drew Adams <=
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', Drew Adams, 2012/04/18