[COMMIT] Deal with buffer-reversion with non-binary coding better; update comment

[Aidan Kehoe]

APPROVE COMMIT

NOTE: This patch has been committed.

lisp/ChangeLog addition:

2006-10-27  Aidan Kehoe  <kehoea at parhasard.net>

	* files.el (revert-buffer-internal):
	When reverting, use the buffer-file-coding-system of the file's
	buffer when determing whether something has changed on disk. 
	

src/ChangeLog addition:

2006-10-27  Aidan Kehoe  <kehoea at parhasard.net>

	* fileio.c (Finsert_file_contents_internal) : Clarify that we
	follow a more correct but more expensive design for buffers where
	the on-disk representation doesn't correspond directly to the
	XEmacs internal representation. 


XEmacs Trunk source patch:
Diff command:   cvs -q diff -Nu
Files affected: src/fileio.c lisp/files.el

Index: lisp/files.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/lisp/files.el,v
retrieving revision 1.75
diff -u -u -r1.75 files.el
--- lisp/files.el	2005/11/13 07:39:29	1.75
+++ lisp/files.el	2006/10/27 19:02:49
@@ -3521,7 +3521,10 @@
 	      after-change-function
 	      after-change-functions
 	      before-change-function
-	      before-change-functions)
+	      before-change-functions
+	      ;; #### b-f-c-s is _not necessarily_ the coding system that
+	      ;; was used to read in the file. See its docstring.
+	      (coding-system-for-read buffer-file-coding-system))
 	  (if revert-buffer-insert-file-contents-function
 	      (funcall revert-buffer-insert-file-contents-function
 		       file-name nil)
Index: src/fileio.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/fileio.c,v
retrieving revision 1.105
diff -u -u -r1.105 fileio.c
--- src/fileio.c	2006/06/19 18:19:37	1.105
+++ src/fileio.c	2006/10/27 19:02:51
@@ -2948,6 +2948,13 @@
      reasonable maximum file size on the files.  Is any of this worth it?
      --ben
 
+
+       It's probably not worth it, and despite what you might take from the
+       above, we don't do it currently; that is, for non-"binary" coding
+       systems, we don't try to implement replace-mode at all. See the
+       do_speedy_insert variable above. The upside of this is that our API
+       is consistent and not buggy. -- Aidan Kehoe, Fri Oct 27 21:02:30 CEST
+       2006
      */
 
   if (!NILP (replace))

-- 
Santa Maradona, priez pour moi!