Mercurial > hg > xemacs-beta
changeset 3638:305157cf3ebb
[xemacs-hg @ 2006-10-27 19:07:32 by aidan]
Deal with buffer-reversion with non-binary coding better; update fileio.c
comment from Ben.
| author | aidan |
|---|---|
| date | Fri, 27 Oct 2006 19:07:47 +0000 |
| parents | 9ea4f17ba0db |
| children | a8a83fd6ea29 |
| files | lisp/ChangeLog lisp/files.el src/ChangeLog src/fileio.c |
| diffstat | 4 files changed, 24 insertions(+), 1 deletions(-) [+] |
line wrap: on
line diff
--- a/lisp/ChangeLog Thu Oct 26 21:50:59 2006 +0000 +++ b/lisp/ChangeLog Fri Oct 27 19:07:47 2006 +0000 @@ -1,3 +1,9 @@ +2006-10-27 Aidan Kehoe <kehoea@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. + 2006-10-14 Jeff Miller <jmiller@xemacs.org> * info.el (Info-find-emacs-command-nodes): fix regex for find
--- a/lisp/files.el Thu Oct 26 21:50:59 2006 +0000 +++ b/lisp/files.el Fri Oct 27 19:07:47 2006 +0000 @@ -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)
--- a/src/ChangeLog Thu Oct 26 21:50:59 2006 +0000 +++ b/src/ChangeLog Fri Oct 27 19:07:47 2006 +0000 @@ -1,3 +1,10 @@ +2006-10-27 Aidan Kehoe <kehoea@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. + 2006-08-29 Stephen J. Turnbull <stephen@xemacs.org> * eval.c (Fcatch): Correct syntax of `throw' in docstring.
--- a/src/fileio.c Thu Oct 26 21:50:59 2006 +0000 +++ b/src/fileio.c Fri Oct 27 19:07:47 2006 +0000 @@ -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))