Working with one buffer in two frames/windows

Working with one buffer in two frames/windows

[David Kastrup]

Hi,

it is annoyingly impossible to keep working with two views of the same
buffer.  For example, say that I have a file text.tex open in two frames
since I want to work on two different locations of it via
comparison/cut&paste/whatever.

Now I type M-x gnus RET, read news and quit again.  As a consequence, a
totally unrelated buffer pops up.  And of course, when I get back the
buffer again (which is not the default offered), the window point is
lost and replaced by that of the other frame that is still on.

That is quite a nuisance.  Are there some ways to make a two-view setup
less ephemeral?

-- 
David Kastrup

Re: Working with one buffer in two frames/windows

[David Hansen]

On Fri, 11 Jul 2008 12:55:59 +0200 David Kastrup wrote:

> That is quite a nuisance.  Are there some ways to make a two-view setup
> less ephemeral?

clone-indirect-buffer

David

Re: Working with one buffer in two frames/windows

[Stefan Monnier]

> it is annoyingly impossible to keep working with two views of the same
> buffer.  For example, say that I have a file text.tex open in two frames
> since I want to work on two different locations of it via
> comparison/cut&paste/whatever.

> Now I type M-x gnus RET, read news and quit again.  As a consequence, a
> totally unrelated buffer pops up.  And of course, when I get back the
> buffer again (which is not the default offered), the window point is
> lost and replaced by that of the other frame that is still on.

Yes, it's problematic.  Emacs's buffer/window management presumes you
most likely want to display a buffer in only 1 window at a time.
As someone else mentioned you can kind of work around this via
clone-indirect-buffer.

> That is quite a nuisance.  Are there some ways to make a two-view setup
> less ephemeral?

You might want to try and play with window-configs.


        Stefan

Re: Working with one buffer in two frames/windows

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> it is annoyingly impossible to keep working with two views of the same
>> buffer.  For example, say that I have a file text.tex open in two frames
>> since I want to work on two different locations of it via
>> comparison/cut&paste/whatever.
>
>> Now I type M-x gnus RET, read news and quit again.  As a consequence, a
>> totally unrelated buffer pops up.  And of course, when I get back the
>> buffer again (which is not the default offered), the window point is
>> lost and replaced by that of the other frame that is still on.
>
> Yes, it's problematic.  Emacs's buffer/window management presumes you
> most likely want to display a buffer in only 1 window at a time.

It is clearly presuming too much and remembering too little about my
preferences.

> As someone else mentioned you can kind of work around this via
> clone-indirect-buffer.
>
>> That is quite a nuisance.  Are there some ways to make a two-view setup
>> less ephemeral?
>
> You might want to try and play with window-configs.

Do you mean as in "find your own private way to fight Emacs'
misbehavior" or in "somebody should really start working on improving
this, and maybe you could give it a thought"?

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Working with one buffer in two frames/windows

[martin rudalics]

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

Re: Working with one buffer in two frames/windows

[David Kastrup]

martin rudalics <rudalics@gmx.at> 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.  And other things that
likely use the equivalent of bury-buffer don't either.  Doing any C-x 4
like stuff will lose you the point information in the other window,
permanently.  M-x gnus RET in particular will leave a mess after
finishing concerning both window configuration and buffer selection (at
least if you view at least one article and thus get into split view).

One major drawback of many window systems is productivity loss because
you have to move around and rearrange windows in order to get a certain
job done.  And the Emacs windows assignment methods cause similar user
threshing where you have to invest time to regain a working
configuration.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Working with one buffer in two frames/windows

[martin rudalics]

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

It should work correctly as long as the help buffer is shown in one
window only.  It might fail when you show the help buffer in multiple
windows because `view-return-to-alist' is buffer-local.

 > However,
 > killing the view buffer with C-x k RET does not.  And other things that
 > likely use the equivalent of bury-buffer don't either.  Doing any C-x 4
 > like stuff will lose you the point information in the other window,
 > permanently.  M-x gnus RET in particular will leave a mess after
 > finishing concerning both window configuration and buffer selection (at
 > least if you view at least one article and thus get into split view).
 >
 > One major drawback of many window systems is productivity loss because
 > you have to move around and rearrange windows in order to get a certain
 > job done.  And the Emacs windows assignment methods cause similar user
 > threshing where you have to invest time to regain a working
 > configuration.

We could set up a window-local equivalent of `view-return-to-alist' and
every time one quits or otherwise replaces the buffer, the previous,
explicitly placed there, buffer would get restored together with its
window-point and maybe other window-related/buffer-local information.

Alternatively, we could save the current window configuration when
invoking help or gnus and restore that configuration when quitting.
Personally I find this behavior annoying because it also destroys all
other changes in the window configuration I have done in the meantime.
A typical case is the backtrace buffer where I sometimes wind up
investigating the cause of an error in other windows.  When I eventually
decide to quit backtrace, all those new windows get killed too, leaving
me with a configuration I neither want nor need at that time.

Re: Working with one buffer in two frames/windows

[Stephen J. Turnbull]

David Kastrup writes:
 > martin rudalics <rudalics@gmx.at> 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.

Re: Working with one buffer in two frames/windows

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>  > martin rudalics <rudalics@gmx.at> 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

Re: Working with one buffer in two frames/windows

[Stefan Monnier]

> Do you mean as in "find your own private way to fight Emacs'
> misbehavior" or in "somebody should really start working on improving
> this, and maybe you could give it a thought"?

The latter.


        Stefan

Re: Working with one buffer in two frames/windows

[Stephen J. Turnbull]

David Kastrup writes:

 > > (add-hook 'kill-buffer-hook 'View-quit 'append 'local)

 > I am not really all too convinced that one can cover everything in that
 > manner.

Of course not.  My intent was to suggest that view-mode could do an
even better job cleaning up after itself in this small way.

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

The problem is identifying them.  Kyle Jones's VM comes with a library
called tapestry that does a pretty good job of this for VM itself, but
it doesn't help when returning to some other task.  Many tasks seem to
be built up from user-process-specific window and frame groups; how is
Emacs to guess?

I think that you do need a UI to tell Emacs which objects belong
together.  Of course, complex modes could and should do the user of
calling that UI and saving the user the trouble.

 > 
 > -- 
 > David Kastrup, Kriemhildstr. 15, 44793 Bochum
 > 
 > 

Re: Working with one buffer in two frames/windows

[Alan Mackenzie]

Hi, David and everybody else,

On Fri, Jul 11, 2008 at 12:55:59PM +0200, David Kastrup wrote:

> Hi,

> it is annoyingly impossible to keep working with two views of the same
> buffer.  For example, say that I have a file text.tex open in two frames
> since I want to work on two different locations of it via
> comparison/cut&paste/whatever.

Just a slight clarification: the problems are as bad with two views of a
file in two windows within one frame.

> Now I type M-x gnus RET, read news and quit again.  As a consequence, a
> totally unrelated buffer pops up.  And of course, when I get back the
> buffer again (which is not the default offered), the window point is
> lost and replaced by that of the other frame that is still on.

> That is quite a nuisance.

I disagree somewhat on this point.  It is an enormous pain in the cdr,
not "quite a nuisance".

> Are there some ways to make a two-view setup less ephemeral?

I'd like to throw the following idea into the ring for discussion:

Change the 'buffer-list' frame parameter (page "Buffer Parameters" in the
elisp manual) from:

    `buffer-list'
         A list of buffers that have been selected in this frame, ordered
         most-recently-selected first.

to:

    `buffer-list'
         A list of information about buffers that have been selected in this
	 frame, ordered most-recently-selected first.  There is one entry
	 for each buffer, which looks like this:  (BUFFER, POINT, .....)

, where "...." needs to be thought about.  Possibly it could contain
details of the window size, and where in the window point is.  This
information would then be used by C-x k, C-x 4 b, and the like.

> David Kastrup

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Working with one buffer in two frames/windows

[Stefan Monnier]

>     `buffer-list'
>          A list of information about buffers that have been selected in this
> 	 frame, ordered most-recently-selected first.  There is one entry
> 	 for each buffer, which looks like this:  (BUFFER, POINT, .....)

For what it's worth, DocView buffers behave like this (we had to
emulate `point', and we ended up doing it slightly differently than the
real `point', so that it remembers the displayed page for each window
where the buffer was displayed).


        Stefan

Re: Working with one buffer in two frames/windows

[Vincent Belaïche]

Hello,

Just to throw a comment into this discussion from a non-developper : 
something that is quite disturbing to the user is that when you have 
several windows on the same buffer, and you switch on/off narrowing 
(which is quite often the case when you want to limit the scope of some 
search and replace), then you loose the point position on the other 
window after switching narrowing off again.

If this has been changed in Emacs version 23, then forget this mail (I 
am with 22.2).

It is disturbing because all windows are about is looking at several 
point of the same buffer at the same time, and narrowing on/off looses 
this multiplicity of points of view.

My suggestion is that:
1) when going to narrowing on a buffer, points in other windows of the 
same buffer should be stored if they are outside the narrowed region,
2) if during narrowing mode, the user goes to the other window, and 
moves the point, then the other window's before-narrowing-stored-point 
should be erased, and
3) when the user is going out of the narrowing mode, then for each other 
window on the same buffer, if there is before-narrowing-stored-point 
available, it should be restored.

Surely this restoring of the window configuration prior to narrowing 
should be made a defcustom choice (always, never, ask-user). Maybe point 
2 above is not that much needed.

Ideally, narrowing should concern only one window, and not the full 
buffer (in any windows), but maybe this is too much change because 
narrowing has to do with the current buffer mode and making an indirect 
buffer is a better response.

At least this point save&restore thing would be quite useful, especially 
as using a couple of windows is often more practical than using 
registers to store a point, even though more ephemeral, just as window 
handling command (C-x 2, C-x 1, C-x 0) are of quite easy access.

BR,
  Vincent.