Re: Buffer's point changes when frame closed.
On Thu, 09 Jan 2003, stephen(a)xemacs.org wrote:
>>>>> "Bryan" == Bryan Kramer
<kramer(a)techne.ca> writes:
Bryan> I often have many frames open on many different buffers. I
Bryan> frequently close most or all but one of these
Bryan> frames. Having done this, sometimes opening a frame on a
Bryan> buffer that I have looked at before, the visible area and
Bryan> point are nowhere near where I left them when I closed the
Bryan> last frame on the buffer. I don't expect point to change
Bryan> just because I closed a frame.
OK, that's a bug. But we need to know what modes these buffers with
changing point are in, and it would be best if you can provide us with
a recipe like
If you have the same buffer in multiple frames, the point of the
second frame will get the point of the first frame. This can be seen
in fundamental mode.
frame1: 1) Open a file in fundamental mode, text mode will probably work.
2) Put the mark somewhere distinctive in the buffer.
3) Leave this frame open on the file
frame2: 1) Open a new frame for the same file.
The new frame opens at the frame1's point
2) Jump somewhere else in the file.
3) switch buffers away from file.
4) switch buffers back to file.
5) My point is back to frame1's point, not where I left it
before switching buffers.
Basically, you can have multiple frames looking at a file, but you
(kind of) only get one point the multiple frames share.
-jeff
xemacs -nw
C-x C-f new-file
; insert text and move
; alternatively, find a file it happens on that you can send us or put
; up on the Web for retrieval
C-x 5 C-f some-other-file
C-x 5 o
C-x 5 0
C-x 5 b new-file
; point is wrong
Also, if it's consistently in one of the big externally maintained
packages like JDE or cc-mode, you should file bug reports with the
maintainers. It seems possible to me that one of this packages is
doing something "intelligent" outside of a save-excursion or the like;
there's nothing we can do about that kind of thing except ask the
maintainers to fix.
It's especially plausible with JDE because (a) it's very intelligent
and (b) I don't use it which is consistent with me not having observed
the bug.