* Working with one buffer in two frames/windows @ 2008-07-11 10:55 David Kastrup 2008-07-11 11:28 ` David Hansen ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: David Kastrup @ 2008-07-11 10:55 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-11 10:55 Working with one buffer in two frames/windows David Kastrup @ 2008-07-11 11:28 ` David Hansen 2008-07-12 2:24 ` Stefan Monnier 2008-07-13 13:06 ` Alan Mackenzie 2 siblings, 0 replies; 14+ messages in thread From: David Hansen @ 2008-07-11 11:28 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-11 10:55 Working with one buffer in two frames/windows David Kastrup 2008-07-11 11:28 ` David Hansen @ 2008-07-12 2:24 ` Stefan Monnier 2008-07-12 8:21 ` David Kastrup 2008-07-13 13:06 ` Alan Mackenzie 2 siblings, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2008-07-12 2:24 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-12 2:24 ` Stefan Monnier @ 2008-07-12 8:21 ` David Kastrup 2008-07-12 10:40 ` martin rudalics 2008-07-12 21:20 ` Stefan Monnier 0 siblings, 2 replies; 14+ messages in thread From: David Kastrup @ 2008-07-12 8:21 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-12 8:21 ` David Kastrup @ 2008-07-12 10:40 ` martin rudalics 2008-07-12 11:02 ` David Kastrup 2008-07-12 21:20 ` Stefan Monnier 1 sibling, 1 reply; 14+ messages in thread From: martin rudalics @ 2008-07-12 10:40 UTC (permalink / raw) To: David Kastrup; +Cc: Stefan Monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-12 10:40 ` martin rudalics @ 2008-07-12 11:02 ` David Kastrup 2008-07-12 12:22 ` martin rudalics 2008-07-12 20:40 ` Stephen J. Turnbull 0 siblings, 2 replies; 14+ messages in thread From: David Kastrup @ 2008-07-12 11:02 UTC (permalink / raw) To: martin rudalics; +Cc: Stefan Monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-12 11:02 ` David Kastrup @ 2008-07-12 12:22 ` martin rudalics 2008-07-12 20:40 ` Stephen J. Turnbull 1 sibling, 0 replies; 14+ messages in thread From: martin rudalics @ 2008-07-12 12:22 UTC (permalink / raw) To: David Kastrup; +Cc: Stefan Monnier, emacs-devel >>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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-12 11:02 ` David Kastrup 2008-07-12 12:22 ` martin rudalics @ 2008-07-12 20:40 ` Stephen J. Turnbull 2008-07-12 20:41 ` David Kastrup 1 sibling, 1 reply; 14+ messages in thread From: Stephen J. Turnbull @ 2008-07-12 20:40 UTC (permalink / raw) To: David Kastrup; +Cc: martin rudalics, Stefan Monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-12 20:40 ` Stephen J. Turnbull @ 2008-07-12 20:41 ` David Kastrup 2008-07-12 22:53 ` Stephen J. Turnbull 0 siblings, 1 reply; 14+ messages in thread From: David Kastrup @ 2008-07-12 20:41 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: martin rudalics, Stefan Monnier, emacs-devel "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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-12 20:41 ` David Kastrup @ 2008-07-12 22:53 ` Stephen J. Turnbull 0 siblings, 0 replies; 14+ messages in thread From: Stephen J. Turnbull @ 2008-07-12 22:53 UTC (permalink / raw) To: David Kastrup; +Cc: martin rudalics, Stefan Monnier, emacs-devel 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 > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-12 8:21 ` David Kastrup 2008-07-12 10:40 ` martin rudalics @ 2008-07-12 21:20 ` Stefan Monnier 1 sibling, 0 replies; 14+ messages in thread From: Stefan Monnier @ 2008-07-12 21:20 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-11 10:55 Working with one buffer in two frames/windows David Kastrup 2008-07-11 11:28 ` David Hansen 2008-07-12 2:24 ` Stefan Monnier @ 2008-07-13 13:06 ` Alan Mackenzie 2008-07-14 1:44 ` Stefan Monnier 2 siblings, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2008-07-13 13:06 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-13 13:06 ` Alan Mackenzie @ 2008-07-14 1:44 ` Stefan Monnier 2008-07-22 5:45 ` Vincent Belaïche 0 siblings, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2008-07-14 1:44 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel > `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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Working with one buffer in two frames/windows 2008-07-14 1:44 ` Stefan Monnier @ 2008-07-22 5:45 ` Vincent Belaïche 0 siblings, 0 replies; 14+ messages in thread From: Vincent Belaïche @ 2008-07-22 5:45 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2008-07-22 5:45 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-07-11 10:55 Working with one buffer in two frames/windows David Kastrup 2008-07-11 11:28 ` David Hansen 2008-07-12 2:24 ` Stefan Monnier 2008-07-12 8:21 ` David Kastrup 2008-07-12 10:40 ` martin rudalics 2008-07-12 11:02 ` David Kastrup 2008-07-12 12:22 ` martin rudalics 2008-07-12 20:40 ` Stephen J. Turnbull 2008-07-12 20:41 ` David Kastrup 2008-07-12 22:53 ` Stephen J. Turnbull 2008-07-12 21:20 ` Stefan Monnier 2008-07-13 13:06 ` Alan Mackenzie 2008-07-14 1:44 ` Stefan Monnier 2008-07-22 5:45 ` Vincent Belaïche
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).