unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* Fwd: Re: Unrecognized \ sequences and Elisp
@ 2004-01-27  3:37 Roland Orre
  2004-01-27  9:04 ` Paul Jarc
  0 siblings, 1 reply; 15+ messages in thread
From: Roland Orre @ 2004-01-27  3:37 UTC (permalink / 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


^ permalink raw reply	[flat|nested] 15+ messages in thread
* Unrecognized \ sequences and Elisp
@ 2004-01-26 23:26 Neil Jerram
  2004-01-27  2:45 ` Paul Jarc
  0 siblings, 1 reply; 15+ messages in thread
From: Neil Jerram @ 2004-01-26 23:26 UTC (permalink / raw)


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.)

What should we do about this?  Is it reasonable to again allow "\(" as
a special case - perhaps only when SCM_ELISP_READ_EXTENSIONS is
defined - or do we need to implement the Elisp reader completely
independently of the Guile reader?

        Neil



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


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2004-02-18 21:10 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-27  3:37 Fwd: Re: Unrecognized \ sequences and Elisp Roland Orre
2004-01-27  9:04 ` 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
  -- strict thread matches above, loose matches on Subject: below --
2004-01-26 23:26 Neil Jerram
2004-01-27  2:45 ` Paul Jarc
2004-01-27  6:44   ` Stephen Compall
2004-01-27  8:55     ` Paul Jarc
2004-01-28 16:32       ` Neil Jerram

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).