diff admin/FOR-RELEASE @ 90054:f2ebccfa87d4

Revision: [e-mail]--gnu-2004/emacs--unicode--0--patch-74 Merge from emacs--cvs-trunk--0 Patches applied: * [e-mail]--gnu-2004/emacs--cvs-trunk--0--patch-709 Update from CVS: src/indent.c (Fvertical_motion): Fix last change. * [e-mail]--gnu-2004/emacs--cvs-trunk--0--patch-710 - [e-mail]--gnu-2004/emacs--cvs-trunk--0--patch-715 Update from CVS * [e-mail]--gnu-2004/emacs--cvs-trunk--0--patch-716 Merge from gnus--rel--5.10 * [e-mail]--gnu-2004/gnus--rel--5.10--patch-74 Update from CVS

--- a/admin/FOR-RELEASE	Mon Dec 06 12:38:25 2004 +0000
+++ b/admin/FOR-RELEASE	Wed Dec 08 05:02:30 2004 +0000
@@ -36,6 +36,32 @@
 
 * BUGS
 
+** Ange-ftp should ignore irrelevant IPv6 errors:
+
+Message-Id: <[e-mail]>
+From: "Piet van Oostrum" <[e-mail]>
+To: [e-mail]
+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 @@
 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 @@
 	 (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 @@
 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: