Re: Buffer's point changes when frame closed.

ms> Previous messages in this thread explain it: If they did, I wouldn't have asked. ;-) ms> I conjecture this assumption was born in the time before ms> multiple frames. There, you always type into the selected ms> window, which is why you want the invariant the way it is. And in multiple frames you can type into an unselected window? Huh? I don't think frames have anything to do with this, except that it makes it easier to fail to notice that a misbehaving program has changed buffer point on you. ms> Now, it makes sense if the selected window *of the selected ms> frame* maintains that invariant, but not for *all* frames. That's easy for you to say. Now turn it into a coherent specification of a unique point associated to a buffer. And it has to be a unique point: the OP is talking about a case where all frames containing windows displaying that buffer have been closed, so a frame -> frame-buffer-point mapping makes no sense. Note first that if a window is still open, its point doesn't move. If you don't select the window, you don't see point. When you select that window, buffer point moves there. So what you're saying, apparently, is that if you close that frame when the window is _un_selected, in some cases that should move buffer point to the unselected window's point. Huh?? How is XEmacs supposed to guess when that is appropriate? If it is the window point-buffer point synchronization that is causing his problem, it must be the case that the last selected window displaying that buffer was not the one he considers the "principal view" of that buffer. I don't see how XEmacs can intuit which is the "principal view"---most recently selected window is a simple rule that will get it right almost all of the time. (Unless there are apps that are selecting windows on buffers behind the user's back. Shouldn't they be using `save-excursion'? Or an indirect buffer?) Nor will the heuristic of keeping a per-frame list of buffer points and using the last one closed get this right, because that will often override the user's explicit last selection. This would force users to close frames, maybe even windows, in a specific order (namely, the window whose point they want saved in the buffer's point last). -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.