From: "Drew Adams" <drew.adams@oracle.com>
To: "martin rudalics" <rudalics@gmx.at>
Cc: bug-gnu-emacs@gnu.org, dashteacup@insightbb.com
Subject: RE: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t
Date: Thu, 18 Oct 2007 15:58:00 -0700 [thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICEELDEAAA.drew.adams@oracle.com> (raw)
In-Reply-To: <4717D7B2.5030608@gmx.at>
> > I have a dedicated *Help* frame.
>
> What is the semantics of a "dedicated frame"?
I should have said "special-display".
(add-to-list
'special-display-buffer-names
(list "*Help*" 'my-display-*Help*-frame...))
> > Because of `pop-up-frames', `display-buffer' uses another
> > frame, but I do sometimes switch to a different buffer in
> > the same window. And I do sometimes split a window, so my
> > frames are not always `one-window-p'.
>
> If you "dedicate" a frame to the Help buffer why do you want to switch
> to a different buffer in that frame? Why do you want to split that
> frame's window?
I don't; I never said I did. I was describing my overall use, including my
use of `pop-up-frames', not my use of *Help*. You expressed some assumptions
about users with non-nil `pop-up-frames' and their never reusing a window
and never splitting a window. I was explaining that although I have
`pop-up-frames' non-nil, I still sometimes reuse or split some windows (not
*Help*, but others).
> > If a new window or frame was popped up to display a view-mode
> > buffer, then I expect quitting to delete the window and, if
> > one-window-p, delete the frame too.
>
> I already explained that by default Help buffers are not dedicated thus
> `quit-window' won't necessarily delete the associated frame.
And I explained that I don't personally need you to delete the frame - I do
that myself. Deleting the window is sufficient (for *Help* or any other
buffer).
> If people want that we can change the behavior of view-mode
> but that would affect all clients of view-mode. Alternatively
> we could make help-windows dedicated (if that helps).
>
> Currently `view-remove-frame-by-deleting' has to be set to get the
> effect you want. We could make that non-nil by default.
I don't know or care what the default value is.
FWIW, I have that set to `t'.
> > FWIW, my own code takes care of the latter part, so it is
> > enough for me if the view-mode code simply does `quit-window'.
> >
> > If a new window or frame was not popped up to display the
> > view-mode buffer, that is, if I manually switched to it in
> > an existing window, then I want quitting that buffer/mode
> > to restore the previous buffer that was in that window.
> >
> > Summary:
> > if pop-up, then quit => delete the window/frame
> > if not pop-up, then quit => restore previous buffer for window
>
> Suppose you (1) pop up a view-mode window, (2) display a non view-mode
> buffer in that window, (3) display a view-mode buffer in that window,
> and (4) quit view-mode. Whatever `view-mode-exit' does now, you'll
> complain.
No I won't. In that case, you can show again the non-view-mode buffer that
inhabited the window before the view-mode buffer that was quit.
If there was a buffer in the window before the view-mode buffer is placed in
it, then it's OK to show that buffer after quitting the view-mode buffer. If
there was no other buffer in the window before the view-mode buffer, then
there is no reason to display any buffer at all there - just delete the
window. And if the view-mode buffer is `one-window-p', then delete the frame
also.
> >>- Exiting view-mode should ideally (1) kill a window that
> >> has been popped up for view-mode purposes and (2) show
> >> the earlier contents of the window when it has been
> >> usurpated by view-mode.
> >
> > That would be good. In my case, #1 is what I expect for the
> > *Help* buffer. I have no problem with #2, assuming that it
> > applies to buffers that were not popped up in another window.
>
> I wrote "ideally" and I had your usage pattern in mind. But keep in
> mind that killing a window doesn't necessarily imply killing its frame.
I understand. Don't worry about the frame-killing part, at least for me. My
own code does that.
I personally think that the test of `one-window-p' should be sufficient for
deciding whether `delete-window' should also delete the frame, but I think
that some others might disagree with that. For my own needs, it is enough
that Emacs delete the window - my own code will then DTRT (for me) wrt the
frame.
> > I haven't followed the current thread closely. If you have a
> > Lisp-only patch I can try, I will do that.
>
> It's still the patch I sent you earlier.
Then I already provided my feedback, IIRC.
Thanks for working on this, BTW. I realize that it is not so easy to juggle
the many possibilities, including different use patterns.
next prev parent reply other threads:[~2007-10-18 22:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <D64B7FD7-2C5F-4A87-8F0B-61EB47217262@insightbb.com>
2007-10-13 17:28 ` View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t David Reitter
2007-10-14 8:42 ` martin rudalics
2007-10-17 20:58 ` Glenn Morris
2007-10-18 8:20 ` martin rudalics
2007-10-18 16:05 ` Drew Adams
2007-10-18 22:01 ` martin rudalics
2007-10-18 22:58 ` Drew Adams [this message]
2007-10-19 8:23 ` martin rudalics
2007-10-19 15:17 ` Drew Adams
2007-10-20 9:45 ` martin rudalics
2007-10-18 18:27 ` Glenn Morris
2007-10-18 22:03 ` martin rudalics
2007-10-18 23:44 ` Glenn Morris
2007-10-19 8:14 ` martin rudalics
2007-10-19 17:52 ` Glenn Morris
2007-10-20 9:45 ` martin rudalics
2007-10-23 23:30 ` Glenn Morris
2007-10-24 6:32 ` martin rudalics
2007-10-22 21:45 ` David Reitter
2007-11-29 9:05 ` David Reitter
2007-11-29 10:22 ` martin rudalics
[not found] ` <mailman.4303.1196332542.18990.bug-gnu-emacs@gnu.org>
2007-12-01 8:01 ` David Reitter
2007-12-01 9:20 ` martin rudalics
2007-12-01 14:44 ` David Reitter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DNEMKBNJBGPAOPIJOOICEELDEAAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
--cc=bug-gnu-emacs@gnu.org \
--cc=dashteacup@insightbb.com \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.