* Hoehle, Joerg-Cyril [2006-01-20 18:58+0100] writes:

Helmut Eller wrote:

...

The user has to choose an encoding that actually works

I had hoped for auto-detection, or at least reasonable defaults and consistent settings. E.g. I found a message in the *inferior-lisp* buffer ("event-history end") saying that iso-8859-1 was used.

iso-8859-1 is the encoding for the connection between Emacs and Lisp.

However, the buffer's mode line says "u". Same for the slime-repl and *slime-events* buffers. Same for many other buffers in Emacs (e.g. Dired), while Lisp source buffers mostly say "--", i.e. ASCII.

The modeline indicates the buffer-file-coding-system.

.slime-history.eld says -*- utf-8-unix (but so far there's only ASCII therein).

This is Emacs-21.4 on a Ubuntu Breezy i386 with the default clisp-2.35 (not self compiled) -- with #+UNICODE.

How comes? Is that 1/3 a bug-report?

I don't understand the problem.

iso-8859-1 is the default for the connection (because most Lisps support that) and utf-8-unix for the history file (because that's the most general encoding). The buffer-file-coding-system depends (usually) on your setting for the language environment. See `M-x set-language-environment'.

What's unreasonable about those defaults?

...

because the packet length field isn't interpreted correctly and the payload of the packet will be truncated

I wasn't aware slime is sending packets. I thought it's all Lisp data, readable with READ :)

Well, the length field isn't READable; the payload is.

I think it's then ok to modify the patch to assert :iso-8859-1 on a non unicode clisp. And let the user figure out how to set this???

To set what? slime-net-coding-system? The default is already :iso-8859-1.

If a user is so enamored of Unicode, he should have enough clue about those coding issues and be able to read up about slime-net-coding-system in the manual.

Helmut.