Fwd: Re: Unrecognized \ sequences and Elisp

[Roland Orre]

I'm a little concerned about the idea that general string handling
should include interpretation of the content of the string. I don't
really like it. We will get more and more issues like the one below
about elisp.

R5RS defines only \\ and \";  ``Scheme does not specify the effect
of  a  backslash  within  a  string that  is  not  followed  by  a
doublequote or backslash.

I consider the reason for escape sequences in strings is to be able
to express a " within a string, i.e. to be able to express a
character that we would otherwise not be able to put in the string.

I consider that it is better to have routines like read-ansi-string
and write-ansi-string, which was previously suggested, and otherwise
leave the rest of formatting to specific format strings as general
interpretation of escape sequences within strings will affect the
general handling of strings in different applications.

I think it is better to go back to the R5RS specification, which I
consider has been somewhat misinterpreted.
        Best regards
        Roland Orre

On Tue, 2004-01-27 at 03:45, Paul Jarc wrote:
> Neil Jerram <address@hidden> wrote:
> > The recent change to signal an error for "unrecognized" \ sequences
> > has negatively affected the Elisp translator, because Elisp code often
> > uses "\(" in doc strings.  (I think this is when the "(" would
> > otherwise be in column 0, to avoid Emacs thinking that it is the start
> > of a new defun.)
> 
> Would it work to change the Emacs docstrings to look like this?
> "foo...\
> \n(bar...)"
> 
> > Is it reasonable to again allow "\(" as a special case
> 
> That would avoid the need to edit the Emacs sources, though it's a bit
> ugly.  I guess the Right Way would be to fix Emacs so it doesn't get
> confused by parentheses inside strings.
> 
> 
> paul