Re: Raw string literals in Emacs lisp.

[Matthew Plant]

> How about using a Unicode character as the marker? (prepares for stoning)

I'm on the fence about this idea. It certainly would make parsing in reverse possible (assuming the reverse parsing functions do not operate on char *) and easy, but it would also possibly mess up formatting. It also might not add much convenience because frankly typing non-unicode characters is _hard_.

 One suggestion would be to use the unicode left and right double/single quotation marks.

On Wed, Jul 30, 2014 at 1:54 PM, Ted Zlatanov <address@hidden> wrote:

On Wed, 30 Jul 2014 13:41:19 -0700 David Caldwell <address@hidden> wrote:

DC> On 7/30/14 1:28 PM, Ted Zlatanov wrote:
>> On Sun, 27 Jul 2014 13:58:37 -0700 David Caldwell <address@hidden> wrote:
>>
DC> Why not, then, skip rawstrings completely and go directly to a regular
DC> _expression_ reader: #r// (or even just #//) instead of #r""?
>>
>> For shell commands, for instance, it would be convenient to have
>> rawstrings because they often have internal backslash escapes.

DC> That's precisely the point I made later in my email

Sorry I didn't see it.

DC> rawstrings used in shell don't want things like \n escaped, but
DC> regexps do (otherwise you have to add "\n" literal support to the
DC> regexp engine). There's 2 usages with competing semantics trying to
DC> use one generic interface. I still posit that having a syntax
DC> directly for regexps would be beneficial. And I think focusing on
DC> regexps is more important in Emacs as it happens more than
DC> complicated shell commands.

Heredocs are generally useful and popular and would also be supported by
this syntax.  But please don't take that as a knock against regexp
literal support, it's just not something I have needed.

DC> Sadly it sounds like a the #r// would be a no-go due to the Emacs
DC> requirements of parsing it in reverse (I assume because '/' is a valid
DC> lisp symbol character).

I have no opinion on that, I just want a simple syntax for literal data :)

How about using a Unicode character as the marker? (prepares for stoning)

Ted