The symptom was different (a copy/paste issue) but the phenomenon was the same (files with .arc extension not behaving normally). The cause is indeed that Emacs thinks .arc means an archive file. The solution is here:
The variable you need to change is auto-coding-alist, like this:
(push '("\\.arc$" . utf-8) auto-coding-alist)
The reason this problem was so confusing is that the settings in auto-coding-alist take precedence over some of the other things that seem like they ought to work but don't, like
modify-coding-system-alist (described above) or putting a character-encoding directive like:
-*- coding: utf-8 -*-
at the top of the file. Since it was surprisingly hard to track this down and I only found it on my dozen-th or so Google search, I'm making this comment verbose in the hope that the current thread will surface more easily in the future.
There's a longstanding debate between the two communities about whether or not macros provide any meaningful benefits that Smalltalk blocks don't. (The archives of the LL1 mailing list contain a gold mine of posts on this.) In general, I doubt that most Smalltalk hackers would be very interested in macros in Smalltalk; they'd probably see it as out of sync with the spirit of the language. (Compare this to how Lisp hackers react to the inevitable newbie attempts to "fix" Lisp by removing parentheses or making it infix.)
We know how to package functions and data structures in modular, reusable ways; we don't know how to do that with macros, so macros hurt code reuse.
-- who's "we"? But the post itself is interesting evidence for what one could call Graham's Thesis, the idea that any programming language as powerful as Lisp is isomorphic to Lisp; or that all programming languages can be defined by the subset of Lisp that they exclude. The author argues that this exclusion is necessary and good because it gives a language a distinctive character around which a set of idioms, and therefore a community, can develop more easily.
While I totally agree with Kenny that the author's claims about Lisp have a ring of inexperience to them, I do think that this social/communal prism is an interesting one and that Lisp has some distinctive qualities in this area as in others.
