[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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]