Escape litteral and Emacs lisp mode

[Nicolas et Ryoko]

Brian T Rice <water at tunes.org> writes:

> On Sat, 16 Aug 2003, Nicolas et Ryoko wrote:
> 
> > Hello,
> >
> > using #\^[  as a litteral for  escape makes Emacs'  lisp mode lose
> > the  balance between  opening and  closing parentheses  because it
> > does  not  see  the  bracket  as  part  of  the  litteral.   As  a
> > consequence, beginning-of-defun or C-M-b become inaccurate.
> >
> > Writing  #\^\[  for  escape  fixes  this,  until  ecl  understands
> > #\Escape... :-P
> 
> Can you explain what's going on here a little better? I really don't
> understand at what  level or in what context  you're doing this, let
> alone how to write #\^\[ in emacs in the offending way. :)

You're  right,  my  message was  not  clear...  :\  Here is  a  better
description of the problem.

I am reading the lisp  files in the slate directory. In compiler.lisp,
the definition of the function read-token is as follows:

(defun read-token ... ; line 202
   ...
   (case (get-char stream)
      ...
      (#\e #\^[) ; line 228
      ...

Positioning the cursor manually on the parenthesis at the beginning of
the defun line 202 and typing C-M-f  should bring me to the end of the
defun. Instead,  it does  not move the  cursor and outputs  the error:
forward-sexp: "Scan error: "Unbalanced parentheses", 6810, 21459".

Replacing line 228 by (#\e #\^\[) and redoing C-M-f from the beginning
of  the defun  brings the  cursor to  the end  of the  defun:  now the
bracket is no longer seen by Emacs as opening something.

There  are 2  such occurences  of #\^[  in compiler.lisp,  and  one in
prims.lisp. The syntax #\^\[ is interpreted as #\^[ by clisp, sbcl and
ecl.

Using #\Escape in  the lisp code used in Slate  would not trigger this
Emacs lisp-mode bug, but ecl does not understand #\Escape, so the lisp
files seem to use #\^[ for this reason when they mean #\Escape.

-- 
Nicolas