Coding bug in insert-file-contents-internal

[Nix]

On Fri, 04 Feb 2005, Stephen J. Turnbull wrote:
>>>>>> "nix" == nix  <nix at esperi.org.uk> writes:
> 
>     nix> I'm afraid I've suffered multiple hardware failures and
>     nix> near-crippling RSI over the last year plus, which has pretty
>     nix> much killed my ability to develop *anything* :(
> 
> I am very sorry to hear that.  While I'm glad to hear you're healing,
> you might want to look at Ben's page at www.666.com, and Ben might
> have some advice on configuring XEmacs advantageously.

I have. It's excellent... but the single largest RSI-saver (voice
recognition) doesn't work well when you enunciate as poorly and variably
as I do. So a Maltron keyboard it is, and now, after only a few weeks, I
can't imagine why these keyboards aren't in use *everywhere*.  They whip
the flat pasty white rear of QWERTY keyboards. :)

(My RSI wasn't as bad as Ben's, which sounds (reads?) truly horrific. It
was partially Ben's cautionary example which led me to ease off as hard
as I did, and may well have saved my hands. Thanks, Ben!)

>     nix> The only solution I can think of is to locally bind the
>     nix> codesys argument to `coding-system-for-read' inside
> 
> Ah, OK, put that way I remember this vaguely.  Maybe you did report
> it, or it came up in another context.

Maybe. I'm behind a superfascist corporate firewall right now which
blocks xemacs.org, so I can't check the archives.

>     nix> Finsert_file_contents_internal: would that be acceptable? If
>     nix> it is, I can spin a patch in the next day or so.
> 
> I don't know if it would be acceptable; I'll need to make time to look
> at this and I also want a second opinion from "Dr." Wing.  I would

Please! The last thing I want to do is cause a repeat of the
XEmacs-21.4.8 fiasco.

> appreciate having a patch to look at without promising application,
> but that's up to you.

Will do...

This is a completely tentative patch, bceause I'm still not quite clear
on the interactions of bindings, GCPRO, unwind-protect and the like in
the C layer. I *think* it's pointless to specbind() DEFVAR_LISPed
variables, because it seems to me that this would break the magic link
between the C variable and the Lisp symbol --- the magic forwarding
symbol would wind up on the specbinding stack --- and the C code uses
the variable...  so I've tried to record_unwind_protect it instead. I'm
not quite sure if I've done it right, or if I need to GCPRO something (I
don't think so: stuff on the specbinding stack and stuff in
DEFVAR_LISPed variables are both found by the garbage collector anyway,
right?)  record_unwind_protect()?)


It compiles, I don't know if it runs, I don't know if it's safe, I don't
know if there's a better way to do it:

2005-02-04  Nix  <nix at esperi.org.uk>

	* fileio.c (restore_read_coding_system_unwind): New function.
	(Finsert_file_contents_internal): Locally bind the read coding
	system around file-name-handler-alist calls.

Index: src/fileio.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/fileio.c,v
retrieving revision 1.66.2.6
diff -u -r1.66.2.6 fileio.c
--- src/fileio.c	2004/06/23 01:54:46	1.66.2.6
+++ src/fileio.c	2005/02/04 10:58:06
@@ -298,6 +298,17 @@
   return Fset_marker (point_marker, Qnil, Qnil);
 }
 
+#ifdef FILE_CODING
+/* Restore coding-system-for-read.  */
+
+static Lisp_Object
+restore_read_coding_system_unwind (Lisp_Object coding_system)
+{
+  Vcoding_system_for_read = coding_system;
+  return Qnil;
+}
+#endif
+
 /* Versions of read() and write() that allow quitting out of the actual
    I/O.  We don't use immediate_quit (i.e. direct longjmp() out of the
    signal handler) because that's way too losing.
@@ -2790,6 +2801,11 @@
 				   an unwind_protect */
 
   filename = Fexpand_file_name (filename, Qnil);
+
+#ifdef FILE_CODING
+  record_unwind_protect (restore_read_coding_system_unwind, Vcoding_system_for_read);
+  Vcoding_system_for_read = codesys;
+#endif
 
   /* If the file name has special constructs in it,
      call the corresponding file handler.  */

>     nix> --- Russ Allbery
> 
> anybody who quotes Russ can be forgiven almost anything!

OK, now *that* goes in my sig where Russ can see it. :)

-- 
`Blish is clearly in love with language. Unfortunately,
 language dislikes him intensely.' --- Russ Allbery