unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Roland Orre <orre@nada.kth.se>
Subject: Fwd: Re: Unrecognized \ sequences and Elisp
Date: Tue, 27 Jan 2004 04:37:03 +0100	[thread overview]
Message-ID: <1075174623.23547.960.camel@localhost> (raw)

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 <neil@ossau.uklinux.net> 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





_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


             reply	other threads:[~2004-01-27  3:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-27  3:37 Roland Orre [this message]
2004-01-27  9:04 ` Fwd: Re: Unrecognized \ sequences and Elisp Paul Jarc
2004-01-27 12:50   ` Roland Orre
2004-01-27 16:26     ` tomas
2004-01-27 17:43     ` Stephen Compall
2004-01-28 17:03     ` Neil Jerram
2004-02-08 19:16       ` Neil Jerram
2004-02-08 22:06         ` Marius Vollmer
2004-02-10 19:27           ` Neil Jerram
2004-02-18 21:10             ` Marius Vollmer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1075174623.23547.960.camel@localhost \
    --to=orre@nada.kth.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).