Dear God! I’m using x-emacs for my dissertation, yet, as of last night, it’s decided that everything that is displayed in a buffer (an SML process) should be encoded in some weird font. I swear I pressed nothing to cause this, I just got a warning that appeared saying that it couldn’t load a chinese-charset (why ever it would be loading that, I don’t know). This also isn’t the first idiocy that xemacs has inflicted on me. From time to time, it decides to append an invisible ^G to the end of every line in a file, rendering the contents of the file useless.
I’ve tried EVERYTHING, including start xemacs with LANG=C, LANG=POSIX, setting set-language-environment to English etc. etc. Here’s an example:
forall a : nat, b : nat.
showing {
(g): \<exists>ícè. add ìaè ìbè ícè \<and> add ìbè ìaè ícè
[? needs be shown ?] }
should be (and was until last night):
forall a : nat, b : nat.
showing {
(g): \<exists>c. add a b c \<and> add b a c
[? needs be shown ?] }
Seriously, I got nuthin’, but it does look like a code page issue - maybe something in the wider X environment? Or some emac macro maybe.
I tried to use emacs once. And TeX. And failed completely to get my head around it.
I can use vi, but I never trust it (I regularly quit out of a file rather than commit something random where I screwed it up). During a 4 hour practical Programming exam, vi ate about 50% of my code with .5 hours to go. I cried. Retyped. And didn’t have time to compile it. And passed with a B (the code was damn good and I was married to the lecturers daughter - maybe the code wasn’t that good).
I tried the undo command - I forget what it is now. It did not help. I think my terminal was running slow, I typed ahead too much, got in the wrong mode, and typed a big number followed by dl.
First, do you have backups? One solution would be to work from a backup copy (open two instances of xemacs, one with the messed-up new version and one with a clean(er) old copy; merge the changes in by retyping).
To me this sounds like xemacs might be seeing strange embedded characters and trying to reinterpret the document in a non-ASCII coding system. What are the first few characters in your mode line when you edit that file? Is the file supposed to be plain text (7-bit ASCII, e.g. TeX source), or something else?
Normally (for text files such as TeX and C source) these characters look something like --/-- or ---- (Unix and Windows, respectively), or -/–; if emacs has decided to use a different coding system the second hyphen might be something else, like -u/-- or -J/-- or -1/–. If that’s the case, it’s probably because some 8-bit characters have gotten into the file (e.g., inserted via cut-and-paste from somebody else’s coding system) and confused things. Try deleting them (after making another backup, of course) and see if it works then.
The buffer that the corruption has occurred in is receiving output from a poly-ml process (well, really the Isabelle/IsaPlanner theorem prover, but that’s running on top of poly-ml), i.e. it’s not displaying a file. In the buffer where I’m editing SML code, everything is displayed fine, which is even more infuriating.
OK, so everything I said about backups is irrelevant. Does the buffer’s mode line look normal? Can you find any other unusual characters in the output buffer when you look at it outside emacs?
I don’t know anything about Isabelle or SML. Are these written in Emacs lisp, or are they external applications being used as filters by xemacs? … Control-G is the ASCII bell/alert; do you have some sort of interactive alert notification turned on in Isabelle?
Omphaloskeptic, thanks for your help. I contacted the author of the SML mode that I was using inside xemacs and he suggested uninstalling and updating xemacs. Apparently this is some sort of bug in specific versions of xemacs that surfaces from time to time.
No, they’re both written in SML. The SML mode starts a shell with a poly-sml process inside of it, and IsaPlanner is interpreted by the SML interpreter.
