Re: something is majorly broken with goto-char, goto-line
----- Original Message -----
From: "Jeff Miller" <jmiller(a)cablespeed.com>
To: "Ben Wing" <ben(a)666.com>
Cc: "XEmacs beta list" <xemacs-beta(a)xemacs.org>; "Michael Sperber
[Mr.
Preprocessor]" <sperber(a)informatik.uni-tuebingen.de>
Sent: Saturday, December 14, 2002 2:55 PM
Subject: Re: something is majorly broken with goto-char, goto-line
--------------------------------------------------------------------------------
> (defun jdm-test-case ()
> ""
> (interactive)
> (let ((obuf (current-buffer))
> (original-point (point))
> (string "testing.....")
> (test-buffer (get-buffer-create "TEST-BUFFER")))
> (set-buffer test-buffer)
> (goto-char (point-max))
> (insert string "\n")
> Nobody seemed to try it out when I reported it earlier.... But it
> affects me both with a regular startup and with -vanilla. I believe
> this predates any recent change by Michael :-), and don't necessarily
> hold me to it, but I have a fuzzy recollection that that was about the
> time you (Ben) did your major windows MULE checkin.
>
> --
> Jeff Miller
> jmiller(a)cablespeed.com
>
Ben Wing writes:
> sorry if it's already been complained about, as i'm not currently
> on xemacs-beta.
This sounds like it's the same bug I reported way back in Sept of this
year. I'm still using 21.5.b5 because of this. Every beta since has
had it for me. It totally messes up gnus for me. The affected
function is gnus-dribble-enter. I made up a test case that shows off
the bug.
this is not the same issue. i just tracked down the new problem and it was due
to mike's changes.
in your case, everything works according to documentation.
in this line:
(set-window-point (get-buffer-window (current-buffer))
(point-max))
(get-buffer-window (current-buffer)) returns nil. nil == (selected-window),
i.e. the window still showing the old buffer (e.g. *scratch*). documentation
for set-window-point says this:
Make point value in WINDOW be at position POS in WINDOW's buffer.
If WINDOW is the selected window, this actually changes the buffer's point
instead of the window's point. (The equivalence of the selected window's
point with its buffer's point is maintained throughout XEmacs.)
and that's exactly what's happening.
so the question is, what do you think should happen? i did indeed make a few
window-related changes in my MULE megapatch; mostly, it was this:
/* A table that remembers (in marker form) the value of point in buffers
previously displayed in this window. Switching back to those buffers
causes the remembered point value to become current, rather than the
buffer's point. This is so that you get sensible behavior if you have
a buffer displayed in multiple windows and temporarily switch away and
then back in one window. We don't save or restore this table in a
window configuration, since that would be counterproductive -- we
always want to remember the most recent value of point in buffers we
switched away from. */
WINDOW_SLOT (saved_point_cache)
but it's conceivable that i "fixed" some functions [e.g. set-window-start]
to
conform with their documentation.
hmmmm ..... i just looked and i see the problem. see separately-mailed patch.
(set-window-point (get-buffer-window (current-buffer))
(point-max))
> (bury-buffer test-buffer)
> (save-excursion
> (set-buffer obuf)
> (message "original point is %s, current point is %s"
> original-point
> (point))
> )
> (set-buffer obuf))
> )
>
--------------------------------------------------------------------------------