Re: Working with one buffer in two frames/windows

[David Kastrup]

"Stephen J. Turnbull" <address@hidden> writes:

> David Kastrup writes:
>  > martin rudalics <address@hidden> writes:
>  > 
>  > >> I don't think that the solution lies in user commands.  The behavior for
>  > >> temporary screens like help screens and gnus screens and other stuff is
>  > >> far too egregiously annoying to make it reasonable to require the user
>  > >> to fight for his window configuration each time.
>  > >
>  > > If you have problems with `View-quit' when viewing a help buffer please
>  > > report here.  I have tried to handle that case but might have failed.
>  > 
>  > I just tried for 10-seconds and it might do the right thing.  However,
>  > killing the view buffer with C-x k RET does not.
>
> (add-hook 'kill-buffer-hook 'View-quit 'append 'local)
>
> ?
>
> Yeah, I know, if somebody else does (add-hook ... 'append 'local)
> later they will be hosed; maybe `add-hook' needs a MUST-BE-LAST-P
> argument and error or warn if 'must-be-last has already been used?
>
> Or view-mode could rebind C-x k to something that does the equivalent
> of a before advice which checks if the buffer to kill is the current
> buffer, and if so does an add-one-shot-hook.

I am not really all too convinced that one can cover everything in that
manner.  Maybe windows with unique window-point and/or frame
configurations should be pushed into some history when something
replaces them so that the default behavior will tend to restore them.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum