Escape litteral and Emacs lisp mode

[Brian T Rice]

Oops. I forgot to reply sooner.

Basically, this could be fixed, but it's not really our code, and would
probably not be worth fixing. I hope you don't mind. :)

If it helps, issues like this come up all the time in emacs programming
modes that support escaping for characters and such (try it in Slate: $[
causes such an issue, if I am not mistaken). Coding support for everything
possible just reaches a point of diminishing returns.

The alternative is to use full parsers for the mode, but again, that's
usually a lot more effort. Just bear with it until we get something better
going, please.

On Sat, 17 Aug 2003, Nicolas et Ryoko wrote:
> 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.

-- 
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/