[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: display-buffer-reuse-frames makes View-quit abnormal
From: |
martin rudalics |
Subject: |
Re: display-buffer-reuse-frames makes View-quit abnormal |
Date: |
Sat, 28 Jul 2007 17:07:12 +0200 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
Please CC this and all related postings to emacs-pretest-bug.
> I am not clear about the all the innards of the process of view quit, but
> what about:
> just let
>
>>`help-mode' after (C-h f ...) has done
>
>
>> (setq view-exit-action (lambda (buffer)
>> (or (window-minibuffer-p (selected-window))
>> (one-window-p t)
>> (delete-window))))
`view-exit-action' should care about BUFFER and not about any windows.
> but let
> `quit-window'
> invoked by `view-mode-exit' go without
>
>
>> (switch-to-buffer (other-buffer)))),
`quit-window' is called by functions that have no relation to help,
help-mode, or view-mode. It might be called interactively by you.
Hence, we can't change that without giving it either an additonal,
optional argument or breaking other code.
> and let
> view-mode-exit' go without
>
>
>> (if (window-live-p old-window) ; still existing window
>> (select-window old-window)).
The same goes here: `view-mode-exit' is used by other functions as well.
Usually, selecting old-window won't harm. That's the window where you
called C-h f from.
> Following this line, the effective (delete-window) will be done in the help
> window, with the original buffer in the other window, and then all is
> restored.
Your approach would work for help-mode (it should even work if we _did_
switch buffers in `quit-window' - the window gets deleted anyway). It
might break other modes though that don't set `view-exit-action' and
still expect old-window to get reselected.