Revision: miles@gnu.org--gnu-2004/emacs--unicode--0--patch-74

Merge from emacs--cvs-trunk--0

Patches applied:

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-709
   Update from CVS: src/indent.c (Fvertical_motion): Fix last change.

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-710
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-715
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-716
   Merge from gnus--rel--5.10

 * miles@gnu.org--gnu-2004/gnus--rel--5.10--patch-74
   Update from CVS

1 files changed, 35 insertions, 19 deletions

diff --git a/admin/FOR-RELEASE b/admin/FOR-RELEASE
index 82589d95c77..ca0e16bdec9 100644
--- a/admin/FOR-RELEASE
+++ b/admin/FOR-RELEASE
@@ -36,6 +36,32 @@ invalid pointer from string_free_list.
 
 * BUGS
 
+** Ange-ftp should ignore irrelevant IPv6 errors:
+
+Message-Id: <4121-Tue23Mar2004165249+0100-piet@cs.uu.nl>
+From: "Piet van Oostrum" <piet@cs.uu.nl>
+To: emacs-pretest-bug@gnu.org
+Subject: Ange-ftp can't deal with IPV6/IPV4 fallback
+
+Symptoms:
+
+C-x C-f /ftp.nluug.nl:/
+
+The problem is that the DNS first gives an IPV6 address. However our
+router doesn't do IPV6. Ftp then falls back to IPV4:
+
+ftp> open ftp.nluug.nl
+Trying 2001:610:1:80aa:192:87:102:36...
+ftp: connect to address 2001:610:1:80aa:192:87:102:36: No route to host
+Trying 192.87.102.36...
+Connected to ftp.nluug.nl.
+
+Ange-ftp chokes on the `No route to host' message and doesn't look any
+further. 
+
+I think in the near future we will see more of this problem, so it might be
+time to make anfe-ftp more intelligent.
+
 ** Mailabbrev should quote addresses to correspond to RFC 822.
 See http://article.gmane.org/gmane.emacs.devel/27585
 
@@ -49,15 +75,15 @@ Date: Tue, 28 Sep 2004 16:13:13 +0100
 Fetching a url with url-retrieve can reult in an anrbitrary buffer
 being killed if a 401 (or possibly a 407) result is encountered:
 
-url-http-parse-headers calls url-http-handle-authentication, 
-which can call url-retrieve. 
+url-http-parse-headers calls url-http-handle-authentication,
+which can call url-retrieve.
 
-This results in the current buffer being killed, and a new http buffer 
-being generated. However, when the old http buffer is killed, emacs 
-picks the top buffer from the list as the new current buffer, so by the 
-time we get to the end of url-http-parse-headers, _that_ buffer is marked 
-as dead even though it is not necessarily a url buffer, so next time the 
-url libraries reap their dead buffers, an innocent bystander buffer is 
+This results in the current buffer being killed, and a new http buffer
+being generated. However, when the old http buffer is killed, emacs
+picks the top buffer from the list as the new current buffer, so by the
+time we get to the end of url-http-parse-headers, _that_ buffer is marked
+as dead even though it is not necessarily a url buffer, so next time the
+url libraries reap their dead buffers, an innocent bystander buffer is
 killed instead (and an obsolete http buffer may be left lying around too).
 
 A possible fix (which I am currently using) is to call set-buffer
@@ -74,7 +100,7 @@ on the return value of url-http-parse-headers:
          (set-buffer (url-http-handle-authentication nil)))
 etc ....
 
-which makes sure that it is the right http buffer that is current when 
+which makes sure that it is the right http buffer that is current when
 we come to mark the http buffers as dead.
 
 
@@ -94,16 +120,6 @@ Redisplay may loop if there is an error in some display property, e.g.
 A fix would be to somehow disable handling of display properties if an error
 is encountered.
 
-** Problem with cursor border around images and window-margins:
-
-The border around the image when the cursor is on the image
-flows into the right fringe and margin.
-
-     (progn
-       (auto-image-file-mode 1)
-       (find-file (concat data-directory "splash.xpm"))
-       (set-window-margins (selected-window) 25 25))
-
 
 ** Problem with modeline and window margins: