On Fri, Oct 7, 2011 at 10:00 AM, martin rudalics wrote: > >> Whatever we did here, it would make `switch-to-buffer' behave > >> inconsistently. > > > > But it'd be the natural thing to do, I think. > > I can't tell because I'm a single-frame user. The main argument in > favor of a "retain the previous point" strategy is that it makes no > sense to go to the same position already shown in another frame. But > then what about doing C-x b in a window below another one already > showing the buffer I want to switch to? This is an interesting question. The behavior today closely parallels the multi-frame behavior, so I can see how you feel that making my proposed change would make `switch-to-buffer' inconsistent. But you have reminded me that I have for many years wished for the multi-window-one-frame behavior to be different -- and in essentially the same way I've proposed that the multi-window-multi-frame behavior be changed. Assume you have buffer B open on frame F in windows T, U and V, respectively displaying B at positions P1, P2 and P3. Now in window W, also on F, you C-x b to switch to B. Today it takes you to P1, assuming T is next in the window-list. If no window were currently showing B, then W would display point-min. Let's call this the "existing-window" behavior, as for a new window W it will choose a position from an existing window. If you were to make my proposed multi-frame change, I think you could reasonably choose to retain the existing-window behavior within a frame, as it preserves the current intra-frame buffer-switching semantics. However, over the decades I have noticed that when I have two or more windows open to the same buffer on the same frame, it is almost always because I want to establish N > 1 persistent working locations within that buffer. In fact it is rarely useful to have two windows open to the same buffer location, as they merely echo each other. So I would posit that my "multiple persistent working locations" use case is likely to be the most common reason for users to have N > 1 windows displaying the same buffer in a given frame. The problem with today's "existing-window" behavior is that if you have window T displaying buffer B on frame F at buffer position P, then you can not sustain a *persistent* working location P' in any other window U on F. By "persistent", I specifically mean that in window U, if I switch temporarily away to another buffer and then back, I want to go back to P'. Today it takes me to P: I have lost my working location in U. I have long found this behavior most unfortunate. Ironically, the best workaround is to visit B in window X on a second frame G. Then no matter what happens to the window configuration in F, X will retain its window point at your second working location P'. Trying to work around it within F requires that you disturb your window configuration, or attempt to track your working locations with the mark ring, or some other relatively unnatural workflow. At least, I find it unnatural compared to my desired workflow: - open a window T and display buffer B at position Pt - in window U switch to buffer B (it defaults to Pt, which is fine) - then in U: * move to a different position Pu in B * switch to any other buffer C (e.g. Info, shell, ...) * switch back to buffer B * continue working at Pu This workflow, which I think of as "persistent window positions", would actually be closest to how Emacs works in the most common use case of all: single-frame, single-window. If you are visiting B at position P, and you switch away, then back, you will return to P. It is easy to think of this as the window remembering where you last were in B. If you think of it this way, as I do, then you are constantly surprised that windows suffer from amnesia whenever more than one of them is displaying the same buffer. It feels to me that they should behave as if they are independent. Thus I would be happiest if there were an option such that every window tracks the buffer positions of every buffer that it visits, and when switching back to a buffer B that it has already visited, each window displays B at the same position it last displayed B. If you kill a window, its position list goes away. New windows would start with a nil position list, and the first time they visit a buffer they would use the "existing-window" semantics: use the position of the next window currently displaying the buffer, or else point-min. (It might be confusing to have them choose from the position-list of a window that has previously visited the buffer but is not currently displaying it, so I'd not do that.) Similarly if you kill a buffer, then it is removed from the position lists for all existing windows. If it is recreated, e.g. by opening the file again for file buffers, all windows would initially begin viewing it at point-min. I think "per-window visited-buffer last-position lists" would solve the multi-frame problem (4041). I believe they would also clean up the IMO rather unfortunate existing semantics for same-buffer, same-frame, multiple windows, since the current behavior (a) doesn't parallel the current single-frame, single window behavior, and (b) doesn't allow for multiple temporary "persistent" working locations in multiple windows in a single buffer on a single frame. At the very least it'd be a nice global configuration option. I'm sure you could probably do all this with a package, but it's fairly fundamental -- it would be nice, for example, to be able to enable it by setting a single variable on someone else's Emacs instance while debugging something for them. I have done an exhaustive survey of everyone sitting near me right now, and they both agreed that buffer positions should be "window-local", and that they've been annoyed by it forever as well. Just wanted to cover my bases! ;) -steve