slime and lisp buffer encoding

slime and lisp buffer encoding

[Eric Abrahamsen]

Hi,

I'm using Emacs and slime to do a bit of hunchentoot (lisp web server)  
development, and I'm running into an encoding problem. I don't know  
which of the links in the chain is causing the problem, so I hope  
someone here will see what's going...

Basically, using hunchentoot (with cl-who for html templating)  
involves writing the html templates directly into the source code, and  
I'm discovering that I can't type utf-8 text into these source files.  
Compiling a defun with unicode in it results in an encoding error (I  
believe thrown by slime as the defun gets sent to the repl).

I have set everything I can set (file, keyboard, subprocess IO) to  
utf-8-unix. The weird thing is, I can type a Latin accented a (à) into  
the source without trouble. Hunchentoot seems to use a CONTENT-TYPE of  
iso-8859-1 by default, in which case the à shows up fine in the  
browser. If I set content type to utf-8, my browser garbles the à. So  
my lisp strings must be encoded as iso-8859-1, but how did they get  
that way? And how do I make them utf-8?

I'm using emacs CVS, slime 3.0 alpha, Mac Leopard, ccl version 1.2.  
Hope someone's got a pointer (if only to the slime or hunchentoot  
mailing lists).

Thanks,
Eric

Re: slime and lisp buffer encoding

[Eric]

On Aug 7, 5:52 pm, Eric Abrahamsen <gir...@gmail.com> wrote:
> Hi,
>
> I'm using Emacs and slime to do a bit of hunchentoot (lisp web server)  
> development, and I'm running into an encoding problem. I don't know  
> which of the links in the chain is causing the problem, so I hope  
> someone here will see what's going...
>
> Basically, using hunchentoot (with cl-who for html templating)  
> involves writing the html templates directly into the source code, and  
> I'm discovering that I can't type utf-8 text into these source files.  
> Compiling a defun with unicode in it results in an encoding error (I  
> believe thrown by slime as the defun gets sent to the repl).
>
> I have set everything I can set (file, keyboard, subprocess IO) to  
> utf-8-unix. The weird thing is, I can type a Latin accented a (à) into  
> the source without trouble. Hunchentoot seems to use a CONTENT-TYPE of  
> iso-8859-1 by default, in which case the à shows up fine in the  
> browser. If I set content type to utf-8, my browser garbles the à. So  
> my lisp strings must be encoded as iso-8859-1, but how did they get  
> that way? And how do I make them utf-8?

I'll answer my own question: They got that way because iso-8859-1 is
the default string encoding for OpenMCL. Altering inferior-lisp-
program to add the option "-K utf-8" after the executable results in a
lisp that runs in utf-8 by default. Apologies for the noise.

E

>
> I'm using emacs CVS, slime 3.0 alpha, Mac Leopard, ccl version 1.2.  
> Hope someone's got a pointer (if only to the slime or hunchentoot  
> mailing lists).
>
> Thanks,
> Eric

Re: slime and lisp buffer encoding

[Giovanni Lanzani]

Eric Abrahamsen <girzel@gmail.com> writes:

> Eric Hi,
> Eric
> Eric I'm using Emacs and slime to do a bit of hunchentoot (lisp
> Eric web server) development, and I'm running into an encoding
> Eric problem. I don't know  which of the links in the chain is
> Eric causing the problem, so I hope  someone here will see what's
> Eric going...
> Eric
> Eric Basically, using hunchentoot (with cl-who for html
> Eric templating) involves writing the html templates directly
> Eric into the source code, and  I'm discovering that I can't type
> Eric utf-8 text into these source files.  Compiling a defun with
> Eric unicode in it results in an encoding error (I  believe
> Eric thrown by slime as the defun gets sent to the repl).
> Eric
> Eric I have set everything I can set (file, keyboard, subprocess
> Eric IO) to utf-8-unix. The weird thing is, I can type a Latin
> Eric accented a (à) into  the source without trouble. Hunchentoot
> Eric seems to use a CONTENT-TYPE of  iso-8859-1 by default, in
> Eric which case the à shows up fine in the  browser. If I set
> Eric content type to utf-8, my browser garbles the à. So  my lisp
> Eric strings must be encoded as iso-8859-1, but how did they get
> Eric that way? And how do I make them utf-8?
> Eric
> Eric I'm using emacs CVS, slime 3.0 alpha, Mac Leopard, ccl
> Eric version 1.2. Hope someone's got a pointer (if only to the
> Eric slime or hunchentoot  mailing lists).
> Eric
> Eric Thanks,
> Eric Eric

Hi Eric, I don't know if this is related to another problem I have with
weblogger.el: basically if I write some html code, emacs, when sending
it to the web, screws it up. This does not happen with Emacs 22. Would
you be able to try Emacs 22 and see if this happens?

Thanks

Giovanni

Re: slime and lisp buffer encoding

[Pascal J. Bourguignon]

Eric <girzel@gmail.com> writes:

> On Aug 7, 5:52 pm, Eric Abrahamsen <gir...@gmail.com> wrote:
>> Hi,
>>
>> I'm using Emacs and slime to do a bit of hunchentoot (lisp web server)  
>> development, and I'm running into an encoding problem. I don't know  
>> which of the links in the chain is causing the problem, so I hope  
>> someone here will see what's going...
>>
>> Basically, using hunchentoot (with cl-who for html templating)  
>> involves writing the html templates directly into the source code, and  
>> I'm discovering that I can't type utf-8 text into these source files.  
>> Compiling a defun with unicode in it results in an encoding error (I  
>> believe thrown by slime as the defun gets sent to the repl).
>>
>> I have set everything I can set (file, keyboard, subprocess IO) to  
>> utf-8-unix. The weird thing is, I can type a Latin accented a (à) into  
>> the source without trouble. Hunchentoot seems to use a CONTENT-TYPE of  
>> iso-8859-1 by default, in which case the à shows up fine in the  
>> browser. If I set content type to utf-8, my browser garbles the à. So  
>> my lisp strings must be encoded as iso-8859-1, but how did they get  
>> that way? And how do I make them utf-8?
>
> I'll answer my own question: They got that way because iso-8859-1 is
> the default string encoding for OpenMCL. Altering inferior-lisp-
> program to add the option "-K utf-8" after the executable results in a
> lisp that runs in utf-8 by default. Apologies for the noise.

Moreover, you have to set things up in hunchetoot to send utf-8 data.
Some browser may accept a page declared as iso-8859-1 that actually
contain utf-8 data because it's an error often made, but you will want
to send headers and meta tags matching your data.


* I put on the first line of all my lisp sources:

      ;;;; -*- mode:lisp;coding:utf-8 -*-

  (you may configure emacs to do that my default, but I like it that
  the encoding be "documented" this way in the files).


* I confnigure hunchentoot to use utf-8 by default:

      (defparameter *utf-8*
           (flex:make-external-format :utf-8 :eol-style :lf)
           "The UTF-8 encoding.")
      (setf hunchentoot:*HUNCHENTOOT-DEFAULT-EXTERNAL-FORMAT*  *utf-8*
            hunchentoot:*DEFAULT-CONTENT-TYPE* "text/html; charset=UTF-8")


* In addition in all the pages I build, I put in the <head> section a 

      <meta http-equiv="Content-Type" content="text/html; charset=utf-8> 

  tag.


You can check that everything is ok with Firefox "Page Info" menu item
(I don't remember in what menu).

-- 
__Pascal Bourguignon__