Of course I had to start playing with utf-8-unix as the coding system for communications between emacs/slime and the sbcl backend, and of course I had to test it by trying some commands with non-latin-1 characters in them. Everything went fine until I quit slime, when it wanted to save the history to .slime-history.eld with the latin-1 charset (I have not yet converted to utf-8 for everything I do).
This failed of course, which makes me wonder whether slime-repl-save-history ought to have anticipated this problem, and specified the coding system, perhaps to be the same as communicating with the lisp? Of course, slime-repl-read-history-internal runs into the same snag.
I could fix this for my own part by adding ("\.eld$" . utf-8) to file-coding-system-alist or some other trick like that, or even moving to utf-8 as the default coding for all operations, by setting coding-system-for-write and coding-system-for-read both to utf-8. But slime users should not be forced to such measures just because they use utf-8 to talk to their lisp.
- Harald
* Harald Hanche-Olsen [2005-11-16 23:13+0100] writes:
I could fix this for my own part by adding ("\.eld$" . utf-8) to file-coding-system-alist or some other trick like that, or even moving to utf-8 as the default coding for all operations, by setting coding-system-for-write and coding-system-for-read both to utf-8. But slime users should not be forced to such measures just because they use utf-8 to talk to their lisp.
I added a variable slime-repl-history-file-coding-system which defaults to utf8 if available. I can't think of a much better fix.
Helmut.
+ Helmut Eller heller@common-lisp.net:
| I added a variable slime-repl-history-file-coding-system which | defaults to utf8 if available. I can't think of a much better fix.
Works fine. Thanks.
- Harald
-
Harald Hanche-Olsen -
Helmut Eller