unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* "Raw" string literals for elisp
@ 2021-09-08  1:49 Anna Glasgall
  2021-09-08  7:10 ` Po Lu
                   ` (5 more replies)
  0 siblings, 6 replies; 45+ messages in thread
From: Anna Glasgall @ 2021-09-08  1:49 UTC (permalink / raw)
  To: emacs-devel; +Cc: Anna Glasgall

[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]

[My previous message appears to have been eaten, or at least it's not
showing up in the archive; resending from a different From: address.
Apologies for any duplication]

Hello Emacs developers,

I've long been annoyed by the number of backslashes needed when using
string literals in elisp for certain things (regexes, UNC paths, etc),
so I started work on a patch (WIP attached) to implement support for
"raw" string literals, a la Python r-strings. These are string literals
that work exactly like normal string literals, with the exception that
backslash escapes (except for \") are not processed; \ may freely
appear in the string without need to escape. I've made good progress,
but unfortunately I've run into a roadblock and am not sure what to do
next.

I've successfully taught the elisp reader (read1 in lread.c) how to
read r-strings. I thought I had managed to make lisp-mode/elisp-mode
happy by allowing "r" to be a prefix character (C-x C-e and the
underlying forward-sexp/backward-sexp seemed to work fine at first),
but realized that I ran into trouble with strings containing the
sequence of characters '\\"'.

The reader correctly reads r"a\\"" as a string containing the sequence
of characters 'a', '\', '"', and M-: works. Unfortunately, if I try
sexp-based navigation or e.g. C-x C-e, it falls apart. The parser in
syntax.c, which afaict is what lisp-mode is using to try and find sexps
in buffer text, doesn't seem to know what to do with this expression.
I've spent some time staring at syntax.c, but I must confess that I'm
entirely defeated in terms of what changes need to be made here to
teach this other parser about prefixed strings in where the prefix has
meaning that affects the interpretation of the characters between
string fences.

I've attached a copy of my WIP patch; it's definitely not near final
code quality and doesn't have documentation yet, all of which I would
take care of before submitting for inclusion. I also haven't filled out
the copyright assignment paperwork yet, but should this work reach a
point where it was likely to be accepted, I'd be happy to do that.


I'd very much appreciate some pointers on what to try next here, or
some explanation of how syntax.c/syntax.el works beyond what's in the
reference manual. If this is a fool's errand I'm tilting at here, I'd
also appreciate being told that before I sink more time into it :)

thanks,

Anna Glasgall



[-- Attachment #2: rstrings.patch --]
[-- Type: text/x-patch, Size: 3044 bytes --]

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 7ed2d3d08c..e91d81de6d 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -39,6 +39,7 @@ 'emacs-lisp-mode-abbrev-table
 
 (defvar emacs-lisp-mode-syntax-table
   (let ((table (make-syntax-table lisp-data-mode-syntax-table)))
+    (modify-syntax-entry ?r "_ p" table)
     ;; These are redundant, now.
     ;;(modify-syntax-entry ?\[ "(]  " table)
     ;;(modify-syntax-entry ?\] ")[  " table)
diff --git a/src/lread.c b/src/lread.c
index a6c2db5d99..8222c17d0b 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -2970,10 +2970,11 @@ read1 (Lisp_Object readcharfun, int *pch, bool first_in_list)
   bool multibyte;
   char stackbuf[stackbufsize];
   current_thread->stack_top = stackbuf;
-
+  bool raw_literal = false;
   *pch = 0;
 
  retry:
+  raw_literal = false;
 
   c = READCHAR_REPORT_MULTIBYTE (&multibyte);
   if (c < 0)
@@ -3564,7 +3565,23 @@ read1 (Lisp_Object readcharfun, int *pch, bool first_in_list)
 
 	invalid_syntax ("?", readcharfun);
       }
-
+      /* "raw" string literal syntax, a la Python; "raw" literals do
+	 not process escapes except for \" */
+    case 'r':
+      {
+	int next_ch;
+	next_ch = READCHAR;
+	if (next_ch == '\"')
+	  {
+	    raw_literal = true;
+	    /* fall through to string reading */
+	  }
+	else
+	  {
+	    UNREAD (next_ch);
+	    goto read_symbol;
+	  }
+      }
     case '"':
       {
 	ptrdiff_t count = SPECPDL_INDEX ();
@@ -3599,7 +3616,21 @@ read1 (Lisp_Object readcharfun, int *pch, bool first_in_list)
 	    if (ch == '\\')
 	      {
 		int modifiers;
-
+		if (raw_literal)
+		  {
+		    /* still have to handle backslash followed by
+		       double quote even in a raw literal */
+		    int next_ch = READCHAR;
+		    if (next_ch == '\"')
+		      {
+			ch = next_ch;
+		      }
+		    else
+		      {
+			UNREAD(next_ch);
+		      }
+		    goto read_normal_char;
+		  }
 		ch = read_escape (readcharfun, 1);
 
 		/* CH is -1 if \ newline or \ space has just been seen.  */
@@ -3653,6 +3684,7 @@ read1 (Lisp_Object readcharfun, int *pch, bool first_in_list)
 	      }
 	    else
 	      {
+	      read_normal_char:
 		p += CHAR_STRING (ch, (unsigned char *) p);
 		if (CHAR_BYTE8_P (ch))
 		  force_singlebyte = true;
diff --git a/test/src/lread-tests.el b/test/src/lread-tests.el
index dac8f95bc4..964f3da91b 100644
--- a/test/src/lread-tests.el
+++ b/test/src/lread-tests.el
@@ -262,5 +262,15 @@ lread-float
   (should (equal (read "-0.e-5") -0.0))
   )
 
+(ert-deftest lread-string-raw-syntax ()
+  ;; syntax r"a\bc" => string composed of ?a, ?\\, ?b, ?c
+  (should (equal (read "r\"a\\bc\"") "a\\bc"))
+  ;; syntax "a\bc" => string composed of ?a, ?\b, ?c 
+  (should (equal (read "\"a\\bc\"") "a\C-hc"))
+  ;; syntax r"a\"b\"a" => string composed of ?a, ?\", ?b, ?\", ?a
+  (should (equal (read "r\"a\\\"b\\\"a\"") "a\"b\"a"))
+  ;; syntax r"a\\b" => string composed of ?a, ?\\, ?\\, ?b
+  (should (equal (read "r\"a\\\\b\"") "a\\\\b"))
+  )
 
 ;;; lread-tests.el ends here

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

* Re: "Raw" string literals for elisp
  2021-09-08  1:49 "Raw" string literals for elisp Anna Glasgall
@ 2021-09-08  7:10 ` Po Lu
  2021-09-08 14:19   ` Anna Glasgall
  2021-09-08  7:12 ` Lars Ingebrigtsen
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 45+ messages in thread
From: Po Lu @ 2021-09-08  7:10 UTC (permalink / raw)
  To: Anna Glasgall; +Cc: emacs-devel

Anna Glasgall <anna@crossproduct.net> writes:

> I've successfully taught the elisp reader (read1 in lread.c) how to
> read r-strings.

Previously, (r"ab") would be read as a list of the atoms r and "ab".
Does your modification retain compatibility with that behaviour?
Thanks.



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

* Re: "Raw" string literals for elisp
  2021-09-08  1:49 "Raw" string literals for elisp Anna Glasgall
  2021-09-08  7:10 ` Po Lu
@ 2021-09-08  7:12 ` Lars Ingebrigtsen
  2021-09-08 14:20   ` Anna Glasgall
  2021-09-08 11:30 ` Alan Mackenzie
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 45+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-08  7:12 UTC (permalink / raw)
  To: Anna Glasgall; +Cc: emacs-devel

Anna Glasgall <anna@crossproduct.net> writes:

> I've long been annoyed by the number of backslashes needed when using
> string literals in elisp for certain things (regexes, UNC paths, etc),
> so I started work on a patch (WIP attached) to implement support for
> "raw" string literals, a la Python r-strings.

Great!  This would be very welcome, and has been proposed a number of
times before, but nobody has actually implemented it.  As you've found
out, making the reader support the syntax is pretty easy, but the
problem is with getting the rest of the Emacs tooling to understand the
new syntax.  (Which is, in general, the stumbling block when introducing
any new syntax in Emacs Lisp.)

> The reader correctly reads r"a\\"" as a string containing the sequence
> of characters 'a', '\', '"', and M-: works.

I think we'd prefer #r"..." -- # is used in Lisps to introduce most
special syntaxes (and it's more backwards-compatible, since "r" by
itself is a valid read syntax, but #r isn't today).

> Unfortunately, if I try sexp-based navigation or e.g. C-x C-e, it
> falls apart. The parser in syntax.c, which afaict is what lisp-mode is
> using to try and find sexps in buffer text, doesn't seem to know what
> to do with this expression.  I've spent some time staring at syntax.c,
> but I must confess that I'm entirely defeated in terms of what changes
> need to be made here to teach this other parser about prefixed strings
> in where the prefix has meaning that affects the interpretation of the
> characters between string fences.

Hopefully somebody else can give some insights here, because I'm not
overly familiar with syntax.c, either.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



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

* Re: "Raw" string literals for elisp
  2021-09-08  1:49 "Raw" string literals for elisp Anna Glasgall
  2021-09-08  7:10 ` Po Lu
  2021-09-08  7:12 ` Lars Ingebrigtsen
@ 2021-09-08 11:30 ` Alan Mackenzie
  2021-09-08 14:27   ` Anna Glasgall
  2021-09-08 11:34 ` Adam Porter
                   ` (2 subsequent siblings)
  5 siblings, 1 reply; 45+ messages in thread
From: Alan Mackenzie @ 2021-09-08 11:30 UTC (permalink / raw)
  To: Anna Glasgall; +Cc: emacs-devel

Hello, Anna.

Just as a matter of context, I implemented C++ raw strings, and recently
enhanced the code also to handle other CC Mode derived languages such as
C# and Vala.

On Tue, Sep 07, 2021 at 21:49:33 -0400, Anna Glasgall wrote:
> [My previous message appears to have been eaten, or at least it's not
> showing up in the archive; resending from a different From: address.
> Apologies for any duplication]

> Hello Emacs developers,

> I've long been annoyed by the number of backslashes needed when using
> string literals in elisp for certain things (regexes, UNC paths, etc),
> so I started work on a patch (WIP attached) to implement support for
> "raw" string literals, a la Python r-strings. These are string literals
> that work exactly like normal string literals, with the exception that
> backslash escapes (except for \") are not processed; \ may freely
> appear in the string without need to escape. I've made good progress,
> but unfortunately I've run into a roadblock and am not sure what to do
> next.

One not so small point.  How do you put a backslash as the _last_
character in a raw string?

If this is difficult, it may well be worth comparing other languages
with raw strings.  C++ Mode has a complicated system of identifiers at
each end of the raw string (I'm sure you know this).  C# represents a "
inside a multi-line string as "".  Vala (and, I believe, Python) have
triple quote delimters """ and cannot represent three quotes in a row
inside the multi-line string.

It is probably worth while stating explicitly that Elisp raw strings can
be continued across line breaks without having to escape the \n.

> I've successfully taught the elisp reader (read1 in lread.c) how to
> read r-strings. I thought I had managed to make lisp-mode/elisp-mode
> happy by allowing "r" to be a prefix character (C-x C-e and the
> underlying forward-sexp/backward-sexp seemed to work fine at first),
> but realized that I ran into trouble with strings containing the
> sequence of characters '\\"'.

> The reader correctly reads r"a\\"" as a string containing the sequence
> of characters 'a', '\', '"', and M-: works. Unfortunately, if I try
> sexp-based navigation or e.g. C-x C-e, it falls apart. The parser in
> syntax.c, which afaict is what lisp-mode is using to try and find sexps
> in buffer text, doesn't seem to know what to do with this expression.
> I've spent some time staring at syntax.c, but I must confess that I'm
> entirely defeated in terms of what changes need to be made here to
> teach this other parser about prefixed strings in where the prefix has
> meaning that affects the interpretation of the characters between
> string fences.

You probably want to use syntax-table text properties.  See the page
"Syntax Properties" in the Elisp manual.  In short, you would put, say,
a "punctuation" property on most backslashes to nullify their normal
action.  Possibly, you might want such a property on a double quote
inside the string.  You might also want a property on the linefeeds
inside a raw string.  With these properties, C-M-n and friends will work
properly.

Bear in mind that you will also need to apply and remove these
properties as the user changes the Lisp text, for example by removing a
\ before a ".  There is an established mechanism in Emacs for this sort
of action (which CC Mode doesn't use) which I would advise you to use.

> I've attached a copy of my WIP patch; it's definitely not near final
> code quality and doesn't have documentation yet, all of which I would
> take care of before submitting for inclusion. I also haven't filled out
> the copyright assignment paperwork yet, but should this work reach a
> point where it was likely to be accepted, I'd be happy to do that.

Thanks!

> I'd very much appreciate some pointers on what to try next here, or
> some explanation of how syntax.c/syntax.el works beyond what's in the
> reference manual. If this is a fool's errand I'm tilting at here, I'd
> also appreciate being told that before I sink more time into it :)

It is definitely NOT a fool's errand.  There may be some resistance to
the idea of raw strings from traditionalists, but I hope not.  It would
be worth your while really to understand the section in the Elisp manual
on syntax and all the things it can (and can't) do.

Help is always available on emacs-devel.

You're going to have quite a bit of Lisp programming to do.  For
example, font-lock needs to be taught how to fontify a raw string.

But at the end of the exercise, you will have learnt so much about Emacs
that you will qualify as a fully fledged contributor.  :-)

> thanks,

> Anna Glasgall

-- 
Alan Mackenzie (Nuremberg, Germany).



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

* Re: "Raw" string literals for elisp
  2021-09-08  1:49 "Raw" string literals for elisp Anna Glasgall
                   ` (2 preceding siblings ...)
  2021-09-08 11:30 ` Alan Mackenzie
@ 2021-09-08 11:34 ` Adam Porter
  2021-09-08 13:59   ` Clément Pit-Claudel
  2021-09-09  3:09   ` Richard Stallman
  2021-09-08 13:10 ` Stefan Monnier
  2021-09-08 20:40 ` Anna Glasgall
  5 siblings, 2 replies; 45+ messages in thread
From: Adam Porter @ 2021-09-08 11:34 UTC (permalink / raw)
  To: emacs-devel

This would be an exciting feature to have in Elisp.  Thanks for working
on it.

If I may make a somewhat bold, and hopefully not too bikesheddy
suggestion (and one that's probably been made before, when this topic
has come up): Rather than having double-quote characters requiring
escaping in raw strings, would it be possible to do something slightly
Perlescent (I know) and allow the delimiters to be specified?  That
would make them much more useful.  For example, maybe something like:

  #r"foo bar baz"  ;; => "foo bar baz"
  #r|foo "bar" baz|  ;; => "foo \"bar\" baz"

For extra bonus points, it would be nice if leading indentation at the
beginning of a line in a raw string were omitted, similar to Python's
triple-quoted strings.  That would allow docstrings to look something
like:

  (defun foo (arg &optional bar)
    #r|Frobnicate ARG.
       If BAR, require ARG to be "baz".|
    (if (and bar (equal arg "baz"))
        (frobnicate arg)
      (frobnicate arg)))

The delimiter could even be repeated, like:

  #r"""
    foo
    "bar"
    baz
    """
    ;; => "foo\n\"bar\"\nbaz"

Though perhaps I'm getting too far ahead.  :)




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

* Re: "Raw" string literals for elisp
  2021-09-08  1:49 "Raw" string literals for elisp Anna Glasgall
                   ` (3 preceding siblings ...)
  2021-09-08 11:34 ` Adam Porter
@ 2021-09-08 13:10 ` Stefan Monnier
  2021-09-08 14:31   ` Anna Glasgall
  2021-09-08 20:40 ` Anna Glasgall
  5 siblings, 1 reply; 45+ messages in thread
From: Stefan Monnier @ 2021-09-08 13:10 UTC (permalink / raw)
  To: Anna Glasgall; +Cc: emacs-devel

> I've long been annoyed by the number of backslashes needed when using
> string literals in elisp for certain things (regexes, UNC paths, etc),

I most other discussions around this in the past, regexps were the only
significant cases.  I don't know what you have in mind behind the
"etc.", but as for UNC: how often od you use them in ELisp and do you
really need backslashes there (I thought slashes work almost as well in
most of Windows)?

And AFAIC adding raw strings just to halve the number of backslashes in
regexps seems both too much and too little: you'd likely prefer a new
regexp syntax which doesn't require backslashes for grouping
and alternation.


        Stefan "not a big fan of raw strings in ELisp"




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

* Re: "Raw" string literals for elisp
  2021-09-08 11:34 ` Adam Porter
@ 2021-09-08 13:59   ` Clément Pit-Claudel
  2021-09-08 14:12     ` Adam Porter
  2021-09-09  3:09   ` Richard Stallman
  1 sibling, 1 reply; 45+ messages in thread
From: Clément Pit-Claudel @ 2021-09-08 13:59 UTC (permalink / raw)
  To: emacs-devel

On 9/8/21 7:34 AM, Adam Porter wrote:
> For extra bonus points, it would be nice if leading indentation at the
> beginning of a line in a raw string were omitted, similar to Python's
> triple-quoted strings.

Python's triple quoted strings don't omit leading indentation, do they?

  $ python3
  >>> s = """
  ...     aaa
  ...     """
  >>> s
  '\n    aaa\n    '



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

* Re: "Raw" string literals for elisp
  2021-09-08 13:59   ` Clément Pit-Claudel
@ 2021-09-08 14:12     ` Adam Porter
  0 siblings, 0 replies; 45+ messages in thread
From: Adam Porter @ 2021-09-08 14:12 UTC (permalink / raw)
  To: emacs-devel

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 9/8/21 7:34 AM, Adam Porter wrote:
>> For extra bonus points, it would be nice if leading indentation at the
>> beginning of a line in a raw string were omitted, similar to Python's
>> triple-quoted strings.
>
> Python's triple quoted strings don't omit leading indentation, do they?
>
>   $ python3
>   >>> s = """
>   ...     aaa
>   ...     """
>   >>> s
>   '\n    aaa\n    '

You're right, they only have that feature when used as docstrings:
<https://www.python.org/dev/peps/pep-0257/#multi-line-docstrings>




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

* Re: "Raw" string literals for elisp
  2021-09-08  7:10 ` Po Lu
@ 2021-09-08 14:19   ` Anna Glasgall
  0 siblings, 0 replies; 45+ messages in thread
From: Anna Glasgall @ 2021-09-08 14:19 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

On Wed, 2021-09-08 at 15:10 +0800, Po Lu wrote:
> Anna Glasgall <anna@crossproduct.net> writes:
> 
> > I've successfully taught the elisp reader (read1 in lread.c) how to
> > read r-strings.
> 
> Previously, (r"ab") would be read as a list of the atoms r and "ab".
> Does your modification retain compatibility with that behaviour?
> Thanks.

Oops, that's an edge case I hadn't considered. If we want to retain
that behavior I'm going to have to rethink the syntax here (which it
seems like I may want to do anyway based on some other mails on this
thread :/ ). Thanks for giving me another test case!

Anna




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

* Re: "Raw" string literals for elisp
  2021-09-08  7:12 ` Lars Ingebrigtsen
@ 2021-09-08 14:20   ` Anna Glasgall
  0 siblings, 0 replies; 45+ messages in thread
From: Anna Glasgall @ 2021-09-08 14:20 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

On Wed, 2021-09-08 at 09:12 +0200, Lars Ingebrigtsen wrote:
> Anna Glasgall <anna@crossproduct.net> writes:
> 
> > I've long been annoyed by the number of backslashes needed when
> > using
> > string literals in elisp for certain things (regexes, UNC paths,
> > etc),
> > so I started work on a patch (WIP attached) to implement support
> > for
> > "raw" string literals, a la Python r-strings.
> 
> Great!  This would be very welcome, and has been proposed a number of
> times before, but nobody has actually implemented it.  As you've
> found
> out, making the reader support the syntax is pretty easy, but the
> problem is with getting the rest of the Emacs tooling to understand
> the
> new syntax.  (Which is, in general, the stumbling block when
> introducing
> any new syntax in Emacs Lisp.)
> 
> > The reader correctly reads r"a\\"" as a string containing the
> > sequence
> > of characters 'a', '\', '"', and M-: works.
> 
> I think we'd prefer #r"..." -- # is used in Lisps to introduce most
> special syntaxes (and it's more backwards-compatible, since "r" by
> itself is a valid read syntax, but #r isn't today).
> 

That would be fine by me; I'll see about revising this to change the
syntax that.

> > Unfortunately, if I try sexp-based navigation or e.g. C-x C-e, it
> > falls apart. The parser in syntax.c, which afaict is what lisp-mode
> > is
> > using to try and find sexps in buffer text, doesn't seem to know
> > what
> > to do with this expression.  I've spent some time staring at
> > syntax.c,
> > but I must confess that I'm entirely defeated in terms of what
> > changes
> > need to be made here to teach this other parser about prefixed
> > strings
> > in where the prefix has meaning that affects the interpretation of
> > the
> > characters between string fences.
> 
> Hopefully somebody else can give some insights here, because I'm not
> overly familiar with syntax.c, either.
> 

thanks,

Anna




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

* Re: "Raw" string literals for elisp
  2021-09-08 11:30 ` Alan Mackenzie
@ 2021-09-08 14:27   ` Anna Glasgall
  0 siblings, 0 replies; 45+ messages in thread
From: Anna Glasgall @ 2021-09-08 14:27 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

On Wed, 2021-09-08 at 11:30 +0000, Alan Mackenzie wrote:
> Hello, Anna.
> 
> Just as a matter of context, I implemented C++ raw strings, and
> recently
> enhanced the code also to handle other CC Mode derived languages such
> as
> C# and Vala.
> 

Great, I'll definitely take a look at that.

> On Tue, Sep 07, 2021 at 21:49:33 -0400, Anna Glasgall wrote:
> > [My previous message appears to have been eaten, or at least it's
> > not
> > showing up in the archive; resending from a different From:
> > address.
> > Apologies for any duplication]
> 
> > Hello Emacs developers,
> 
> > I've long been annoyed by the number of backslashes needed when
> > using
> > string literals in elisp for certain things (regexes, UNC paths,
> > etc),
> > so I started work on a patch (WIP attached) to implement support
> > for
> > "raw" string literals, a la Python r-strings. These are string
> > literals
> > that work exactly like normal string literals, with the exception
> > that
> > backslash escapes (except for \") are not processed; \ may freely
> > appear in the string without need to escape. I've made good
> > progress,
> > but unfortunately I've run into a roadblock and am not sure what to
> > do
> > next.
> 
> One not so small point.  How do you put a backslash as the _last_
> character in a raw string?

That is an excellent question. I'll need to take a look at how some
other languages handle that :/

Thanks for giving me another test case!

> 
> If this is difficult, it may well be worth comparing other languages
> with raw strings.  C++ Mode has a complicated system of identifiers
> at
> each end of the raw string (I'm sure you know this).  C# represents a
> "
> inside a multi-line string as "".  Vala (and, I believe, Python) have
> triple quote delimters """ and cannot represent three quotes in a row
> inside the multi-line string.
> 
> It is probably worth while stating explicitly that Elisp raw strings
> can
> be continued across line breaks without having to escape the \n.
> 
> > I've successfully taught the elisp reader (read1 in lread.c) how to
> > read r-strings. I thought I had managed to make lisp-mode/elisp-
> > mode
> > happy by allowing "r" to be a prefix character (C-x C-e and the
> > underlying forward-sexp/backward-sexp seemed to work fine at
> > first),
> > but realized that I ran into trouble with strings containing the
> > sequence of characters '\\"'.
> 
> > The reader correctly reads r"a\\"" as a string containing the
> > sequence
> > of characters 'a', '\', '"', and M-: works. Unfortunately, if I try
> > sexp-based navigation or e.g. C-x C-e, it falls apart. The parser
> > in
> > syntax.c, which afaict is what lisp-mode is using to try and find
> > sexps
> > in buffer text, doesn't seem to know what to do with this
> > expression.
> > I've spent some time staring at syntax.c, but I must confess that
> > I'm
> > entirely defeated in terms of what changes need to be made here to
> > teach this other parser about prefixed strings in where the prefix
> > has
> > meaning that affects the interpretation of the characters between
> > string fences.
> 
> You probably want to use syntax-table text properties.  See the page
> "Syntax Properties" in the Elisp manual.  In short, you would put,
> say,
> a "punctuation" property on most backslashes to nullify their normal
> action.  Possibly, you might want such a property on a double quote
> inside the string.  You might also want a property on the linefeeds
> inside a raw string.  With these properties, C-M-n and friends will
> work
> properly.
> 
> Bear in mind that you will also need to apply and remove these
> properties as the user changes the Lisp text, for example by removing
> a
> \ before a ".  There is an established mechanism in Emacs for this
> sort
> of action (which CC Mode doesn't use) which I would advise you to
> use.
> 

It was unclear to me how much additional processing during typing would
be acceptable here as opposed to just running the existing C code.
Hopefully native compilation support will to some extent nullify any
penalty from adding additional logic in Lisp here?

> > I've attached a copy of my WIP patch; it's definitely not near
> > final
> > code quality and doesn't have documentation yet, all of which I
> > would
> > take care of before submitting for inclusion. I also haven't filled
> > out
> > the copyright assignment paperwork yet, but should this work reach
> > a
> > point where it was likely to be accepted, I'd be happy to do that.
> 
> Thanks!
> 
> > I'd very much appreciate some pointers on what to try next here, or
> > some explanation of how syntax.c/syntax.el works beyond what's in
> > the
> > reference manual. If this is a fool's errand I'm tilting at here,
> > I'd
> > also appreciate being told that before I sink more time into it :)
> 
> It is definitely NOT a fool's errand.  There may be some resistance
> to
> the idea of raw strings from traditionalists, but I hope not.  It
> would
> be worth your while really to understand the section in the Elisp
> manual
> on syntax and all the things it can (and can't) do.
> 
> Help is always available on emacs-devel.
> 
> You're going to have quite a bit of Lisp programming to do.  For
> example, font-lock needs to be taught how to fontify a raw string.
> 

I am already moderately familiar with writing elisp at this point, but
yes, I still have a lot to learn :)

> But at the end of the exercise, you will have learnt so much about
> Emacs
> that you will qualify as a fully fledged contributor.  :-)
> 

thanks,

Anna


> > thanks,
> 
> > Anna Glasgall
> 





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

* Re: "Raw" string literals for elisp
  2021-09-08 13:10 ` Stefan Monnier
@ 2021-09-08 14:31   ` Anna Glasgall
  2021-09-08 15:27     ` Mattias Engdegård
                       ` (2 more replies)
  0 siblings, 3 replies; 45+ messages in thread
From: Anna Glasgall @ 2021-09-08 14:31 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

On Wed, 2021-09-08 at 09:10 -0400, Stefan Monnier wrote:
> > I've long been annoyed by the number of backslashes needed when
> > using
> > string literals in elisp for certain things (regexes, UNC paths,
> > etc),
> 
> I most other discussions around this in the past, regexps were the
> only
> significant cases.  I don't know what you have in mind behind the
> "etc.", but as for UNC: how often od you use them in ELisp and do you
> really need backslashes there (I thought slashes work almost as well
> in
> most of Windows)?
> 

Cards on the table here: yes, regexes are 99.999% of the motivation
here :) UNC paths were a somewhat contrived example.

During the course of working on this, I came across the following in I
think syntax.el:


               (while (re-search-forward
"\\(\\\\\\\\\\)\\(?:\\(\\\\\\\\\\)\\|\\((\\(?:\\?[0-
9]*:\\)?\\|[|)]\\)\\)" bound t)

which I feel by itself rather justifies this work.

> And AFAIC adding raw strings just to halve the number of backslashes
> in
> regexps seems both too much and too little: you'd likely prefer a new
> regexp syntax which doesn't require backslashes for grouping
> and alternation.
> 

I would be _thrilled_ to have that, but that seemed like it'd be even
_more_ work than this is already ballooning into. And it does seem to
me that raw-literal syntax is something that'd be generally useful even
outside the use case of regexes.

> 
>         Stefan "not a big fan of raw strings in ELisp"
> 

thanks,

Anna




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

* Re: "Raw" string literals for elisp
  2021-09-08 14:31   ` Anna Glasgall
@ 2021-09-08 15:27     ` Mattias Engdegård
  2021-09-08 15:41       ` Stefan Kangas
  2021-09-08 16:01       ` Alan Mackenzie
  2021-09-08 15:54     ` Stefan Kangas
  2021-09-08 16:05     ` tomas
  2 siblings, 2 replies; 45+ messages in thread
From: Mattias Engdegård @ 2021-09-08 15:27 UTC (permalink / raw)
  To: Anna Glasgall; +Cc: Stefan Monnier, emacs-devel

8 sep. 2021 kl. 16.31 skrev Anna Glasgall <anna@crossproduct.net>:

> Cards on the table here: yes, regexes are 99.999% of the motivation
> here

Elisp actually has a much better regexp syntax than most other languages:

> "\\(\\\\\\\\\\)\\(?:\\(\\\\\\\\\\)\\|\\((\\(?:\\?[0-9]*:\\)?\\|[|)]\\)\\)"

Today that would be written

(rx (group "\\\\")
    (or (group "\\\\")
        (group
         (or (seq "("
                  (? "?" (* digit) ":"))
             (in ")|")))))

which is much more readable and maintainable and less error-prone than what you would get with a new string syntax.




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

* Re: "Raw" string literals for elisp
  2021-09-08 15:27     ` Mattias Engdegård
@ 2021-09-08 15:41       ` Stefan Kangas
  2021-09-08 16:45         ` Mattias Engdegård
  2021-09-08 16:01       ` Alan Mackenzie
  1 sibling, 1 reply; 45+ messages in thread
From: Stefan Kangas @ 2021-09-08 15:41 UTC (permalink / raw)
  To: Mattias Engdegård; +Cc: Emacs developers, Anna Glasgall, Stefan Monnier

Mattias Engdegård <mattiase@acm.org> writes:

> Elisp actually has a much better regexp syntax than most other languages:
>
> > "\\(\\\\\\\\\\)\\(?:\\(\\\\\\\\\\)\\|\\((\\(?:\\?[0-9]*:\\)?\\|[|)]\\)\\)"
>
> Today that would be written
>
> (rx (group "\\\\")
>     (or (group "\\\\")
>         (group
>          (or (seq "("
>                   (? "?" (* digit) ":"))
>              (in ")|")))))
>
> which is much more readable and maintainable and less error-prone than what you would get with a new string syntax.

That's true.  I hope that we can preload rx and use it more.

But ELisp is also intended for end-users that want to hack together
some quick command.  They may be completely uninterested in spending
even a minimum of time to learn rx, and prefer instead to use the more
standard form they already know so they can just get their job done.

I'm not even sure that rx is the unequivocal first choice among
hardcore ELisp programmers.



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

* Re: "Raw" string literals for elisp
  2021-09-08 14:31   ` Anna Glasgall
  2021-09-08 15:27     ` Mattias Engdegård
@ 2021-09-08 15:54     ` Stefan Kangas
  2021-09-08 16:05     ` tomas
  2 siblings, 0 replies; 45+ messages in thread
From: Stefan Kangas @ 2021-09-08 15:54 UTC (permalink / raw)
  To: Anna Glasgall; +Cc: Stefan Monnier, Emacs developers

Anna Glasgall <anna@crossproduct.net> writes:

> During the course of working on this, I came across the following in I
> think syntax.el:
>
>
>                (while (re-search-forward
> "\\(\\\\\\\\\\)\\(?:\\(\\\\\\\\\\)\\|\\((\\(?:\\?[0-
> 9]*:\\)?\\|[|)]\\)\\)" bound t)
>
> which I feel by itself rather justifies this work.

I didn't study your patch, but I for one hope that this feature will
eventually get accepted.  IMHO, it would reduce a not insignificant
pain point for (some types of) programming in Emacs Lisp.

The argument against having "raw" strings in ELisp, if I understand,
it is that it will make some code in core more complex.  This is true,
but it will at the same time make even more code out there less
complex, or at least easier to read and understand.

Once it is fully implemented, there will of course be bugs, but over
time the feature will stabilize.  In the long run I think we will win
more by making Emacs Lisp more attractive (or at least less
unpleasant) to a generation that have already been spoiled by using
raw strings in other languages.



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

* Re: "Raw" string literals for elisp
  2021-09-08 15:27     ` Mattias Engdegård
  2021-09-08 15:41       ` Stefan Kangas
@ 2021-09-08 16:01       ` Alan Mackenzie
  2021-09-08 18:24         ` Mattias Engdegård
  2021-09-08 19:22         ` Philip Kaludercic
  1 sibling, 2 replies; 45+ messages in thread
From: Alan Mackenzie @ 2021-09-08 16:01 UTC (permalink / raw)
  To: Mattias Engdegård; +Cc: emacs-devel, Anna Glasgall, Stefan Monnier

Hello, Mattias.

On Wed, Sep 08, 2021 at 17:27:58 +0200, Mattias Engdegård wrote:
> 8 sep. 2021 kl. 16.31 skrev Anna Glasgall <anna@crossproduct.net>:

> > Cards on the table here: yes, regexes are 99.999% of the motivation
> > here

> Elisp actually has a much better regexp syntax than most other languages:

> > "\\(\\\\\\\\\\)\\(?:\\(\\\\\\\\\\)\\|\\((\\(?:\\?[0-9]*:\\)?\\|[|)]\\)\\)"

> Today that would be written

> (rx (group "\\\\")
>     (or (group "\\\\")
>         (group
>          (or (seq "("
>                   (? "?" (* digit) ":"))
>              (in ")|")))))

> which is much more readable and maintainable and less error-prone than
> what you would get with a new string syntax.

It is more readable in the same way Cobol was very readable; each small
grouping of text is immediately understandable.  But the thing as a
whole?  The rx form of that regexp takes up 6 lines, the string form 1
line.  If there are several regexps in a function rx can lead to a lot of
bloat.  Having the function fit entirely on one's screen contributes a
lot towards readability and maintainability.

It is true the rx form could be squashed onto 1 or 2 lines, but then that
readability is lost.

I have nothing against people who want to use rx, but personally, I
prefer the string form.  How much better a raw string form would be is
difficult to say.

-- 
Alan Mackenzie (Nuremberg, Germany).



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

* Re: "Raw" string literals for elisp
  2021-09-08 14:31   ` Anna Glasgall
  2021-09-08 15:27     ` Mattias Engdegård
  2021-09-08 15:54     ` Stefan Kangas
@ 2021-09-08 16:05     ` tomas
  2021-09-08 16:42       ` Lars Ingebrigtsen
  2021-09-08 20:18       ` Stefan Monnier
  2 siblings, 2 replies; 45+ messages in thread
From: tomas @ 2021-09-08 16:05 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

On Wed, Sep 08, 2021 at 10:31:26AM -0400, Anna Glasgall wrote:
> On Wed, 2021-09-08 at 09:10 -0400, Stefan Monnier wrote:

[...]

> > And AFAIC adding raw strings just to halve the number of backslashes
> > in
> > regexps seems both too much and too little: you'd likely prefer a new
> > regexp syntax which doesn't require backslashes for grouping
> > and alternation.
> > 
> 
> I would be _thrilled_ to have that, but that seemed like it'd be even
> _more_ work than this is already ballooning into [...]

I just think these are two separate dimensions which happen to align
in the "regexp and backslash" case. Fixing each of those has its own
ergonomic potential.

I for one would be very thrilled with raw strings.

> >         Stefan "not a big fan of raw strings in ELisp"

One of those rare cases I tend to disagree with Stefan. Which always
feels funny, because he's most of the time right ;-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

* Re: "Raw" string literals for elisp
  2021-09-08 16:05     ` tomas
@ 2021-09-08 16:42       ` Lars Ingebrigtsen
  2021-09-08 20:08         ` Stefan Monnier
  2021-09-08 20:18       ` Stefan Monnier
  1 sibling, 1 reply; 45+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-08 16:42 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

<tomas@tuxteam.de> writes:

> One of those rare cases I tend to disagree with Stefan. Which always
> feels funny, because he's most of the time right ;-)

Yes, it's very scary the first time it happens.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



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

* Re: "Raw" string literals for elisp
  2021-09-08 15:41       ` Stefan Kangas
@ 2021-09-08 16:45         ` Mattias Engdegård
  0 siblings, 0 replies; 45+ messages in thread
From: Mattias Engdegård @ 2021-09-08 16:45 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Emacs developers, Anna Glasgall, Stefan Monnier

8 sep. 2021 kl. 17.41 skrev Stefan Kangas <stefan@marxist.se>:

> But ELisp is also intended for end-users that want to hack together
> some quick command.  They may be completely uninterested in spending
> even a minimum of time to learn rx, and prefer instead to use the more
> standard form they already know so they can just get their job done.

New reader syntax isn't something to be added lightly. Shouldn't there be a better reason than a belief that some people may be unwilling to learn already existing facilities of the language, especially when those are superior to the proposed addition?

> I'm not even sure that rx is the unequivocal first choice among
> hardcore ELisp programmers.

Their loss then. (And good to know I'm not hardcore!)

It's unfortunate that we've spent the last 50 years teaching generations of programmers that regexps are strings and they use backslashes, to the point that many actually believe it. Failure of education, and lack of proper tools!




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

* Re: "Raw" string literals for elisp
  2021-09-08 16:01       ` Alan Mackenzie
@ 2021-09-08 18:24         ` Mattias Engdegård
  2021-09-08 19:00           ` Alan Mackenzie
  2021-09-08 19:22         ` Philip Kaludercic
  1 sibling, 1 reply; 45+ messages in thread
From: Mattias Engdegård @ 2021-09-08 18:24 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: Anna Glasgall, Stefan Monnier, Emacs developers

8 sep. 2021 kl. 18.01 skrev Alan Mackenzie <acm@muc.de>:

> It is more readable in the same way Cobol was very readable

That comparison is absurdly wrong in many ways: Cobol is not considered readable at all and it was made back when nobody knew how to design languages. I could go on all day about a comparative design history of Cobol, Rx and conventional regexp syntax but will spare you the boredom.

Rx is actually not verbose, definitely not by Lisp standards. You can't use it in CC Mode for reasons of compatibility and that's fine -- engineers often work under constraints not of their own choosing.

I do suggest you give it an honest try in a project where you are permitted to do so. You will be better informed, better equipped to read other people's code, and may come to like it. Even if you don't, you may have something interesting to report from the attempt.

And I'll be there to answer questions!




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

* Re: "Raw" string literals for elisp
  2021-09-08 18:24         ` Mattias Engdegård
@ 2021-09-08 19:00           ` Alan Mackenzie
  0 siblings, 0 replies; 45+ messages in thread
From: Alan Mackenzie @ 2021-09-08 19:00 UTC (permalink / raw)
  To: Mattias Engdegård; +Cc: Emacs developers, Anna Glasgall, Stefan Monnier

Hello, Mattias.

On Wed, Sep 08, 2021 at 20:24:34 +0200, Mattias Engdegård wrote:
> 8 sep. 2021 kl. 18.01 skrev Alan Mackenzie <acm@muc.de>:

> > It is more readable in the same way Cobol was very readable

> That comparison is absurdly wrong

Oh no it's not.

> Rx is actually not verbose .....

The example you gave showed a single line string regexp being equivalent
to a six line rx expression.  That's a factor of 6.  That's verbose by
any measure.

> I do suggest you give it an honest try in a project where you are
> permitted to do so.

rx has been in Emacs, I think, since 21.1.  That was around 20 years
ago.  It hasn't caught on, to any great extent.  If it were that good,
it would have caught on.

> You will be better informed, better equipped to read other people's
> code, and may come to like it. Even if you don't, you may have
> something interesting to report from the attempt.

There are lots of ways of broadening my horizons, even within the scope
of Emacs, but there are only so many hours in a day.

> And I'll be there to answer questions!

OK, here's one: why do think rx is so little used, compared with the
string representation of regular expressions?

-- 
Alan Mackenzie (Nuremberg, Germany).



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

* Re: "Raw" string literals for elisp
  2021-09-08 16:01       ` Alan Mackenzie
  2021-09-08 18:24         ` Mattias Engdegård
@ 2021-09-08 19:22         ` Philip Kaludercic
  2021-09-08 19:36           ` Alan Mackenzie
  2021-09-08 21:11           ` Stefan Kangas
  1 sibling, 2 replies; 45+ messages in thread
From: Philip Kaludercic @ 2021-09-08 19:22 UTC (permalink / raw)
  To: Alan Mackenzie
  Cc: Mattias Engdegård, Anna Glasgall, Stefan Monnier, emacs-devel

Alan Mackenzie <acm@muc.de> writes:

> It is more readable in the same way Cobol was very readable; each small
> grouping of text is immediately understandable.  But the thing as a
> whole?  The rx form of that regexp takes up 6 lines, the string form 1
> line.  If there are several regexps in a function rx can lead to a lot of
> bloat.  Having the function fit entirely on one's screen contributes a
> lot towards readability and maintainability.

The reason I use rx in a lot of my scripts is that I can add comments,
explanations, formatting, etc. when it gets complicated. I think that is
a significant advantage, that even raw strings wouldn't have (unless a
comment syntax were to be added into the regular expression language,
which is unlikely).

-- 
	Philip Kaludercic



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

* Re: "Raw" string literals for elisp
  2021-09-08 19:22         ` Philip Kaludercic
@ 2021-09-08 19:36           ` Alan Mackenzie
  2021-09-08 21:11           ` Stefan Kangas
  1 sibling, 0 replies; 45+ messages in thread
From: Alan Mackenzie @ 2021-09-08 19:36 UTC (permalink / raw)
  To: Philip Kaludercic
  Cc: Mattias Engdegård, Anna Glasgall, Stefan Monnier, emacs-devel

Hello, Philip.

On Wed, Sep 08, 2021 at 19:22:18 +0000, Philip Kaludercic wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > It is more readable in the same way Cobol was very readable; each small
> > grouping of text is immediately understandable.  But the thing as a
> > whole?  The rx form of that regexp takes up 6 lines, the string form 1
> > line.  If there are several regexps in a function rx can lead to a lot of
> > bloat.  Having the function fit entirely on one's screen contributes a
> > lot towards readability and maintainability.

> The reason I use rx in a lot of my scripts is that I can add comments,
> explanations, formatting, etc. when it gets complicated. I think that is
> a significant advantage, that even raw strings wouldn't have (unless a
> comment syntax were to be added into the regular expression language,
> which is unlikely).

Yes, I can see that.  rx certainly has advantages.  But it has
disadvantages too, which Mattias appears not to want to admit exist.  To
be honest, I suspect the differences in readability/maintainability
between the two forms will be small.  Maintaining Emacs, it is most
helpful to have at least a reading competence with both forms.

> -- 
> 	Philip Kaludercic

-- 
Alan Mackenzie (Nuremberg, Germany).



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

* Re: "Raw" string literals for elisp
  2021-09-08 16:42       ` Lars Ingebrigtsen
@ 2021-09-08 20:08         ` Stefan Monnier
  0 siblings, 0 replies; 45+ messages in thread
From: Stefan Monnier @ 2021-09-08 20:08 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: tomas, emacs-devel

Lars Ingebrigtsen [2021-09-08 18:42:41] wrote:
> <tomas@tuxteam.de> writes:
>> One of those rare cases I tend to disagree with Stefan. Which always
>> feels funny, because he's most of the time right ;-)
> Yes, it's very scary the first time it happens.

Indeed, but I got used to it,


        Stefan




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

* Re: "Raw" string literals for elisp
  2021-09-08 16:05     ` tomas
  2021-09-08 16:42       ` Lars Ingebrigtsen
@ 2021-09-08 20:18       ` Stefan Monnier
  2021-09-09  7:04         ` tomas
  2021-09-09 10:30         ` Mattias Engdegård
  1 sibling, 2 replies; 45+ messages in thread
From: Stefan Monnier @ 2021-09-08 20:18 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

> I just think these are two separate dimensions which happen to align
> in the "regexp and backslash" case.

BTW, they can align in somewhat funny ways sometimes.
E.g. the raw-string version of the regexp "[ \t\n]" turns into something like

    #r"[
]"

which is not ideal in terms of clarity.  Similarly a regexp that matches
the NUL character will be problematic when written as a raw string
because it will need to embed the NUL character in the source code,
which in turn will cause tools like `grep` to treat the file as binary.

For the first problem above we can/should extend our regexp syntax to
include \t and \n as regexps that match TAB and LF respectively (that
would also be handy when writing regexps in the minibuffer).
But \0 is already used for other things so there's no such "obvious"
workaround for the second case :-(


        Stefan




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

* Re: "Raw" string literals for elisp
  2021-09-08  1:49 "Raw" string literals for elisp Anna Glasgall
                   ` (4 preceding siblings ...)
  2021-09-08 13:10 ` Stefan Monnier
@ 2021-09-08 20:40 ` Anna Glasgall
  2021-09-08 21:28   ` Alan Mackenzie
  5 siblings, 1 reply; 45+ messages in thread
From: Anna Glasgall @ 2021-09-08 20:40 UTC (permalink / raw)
  To: emacs-devel

On Tue, 2021-09-07 at 21:49 -0400, Anna Glasgall wrote:
> 
[snip]
> I've successfully taught the elisp reader (read1 in lread.c) how to
> read r-strings. I thought I had managed to make lisp-mode/elisp-mode
> happy by allowing "r" to be a prefix character (C-x C-e and the
> underlying forward-sexp/backward-sexp seemed to work fine at first),
> but realized that I ran into trouble with strings containing the
> sequence of characters '\\"'.
> 
> The reader correctly reads r"a\\"" as a string containing the
> sequence
> of characters 'a', '\', '"', and M-: works. Unfortunately, if I try
> sexp-based navigation or e.g. C-x C-e, it falls apart. The parser in
> syntax.c, which afaict is what lisp-mode is using to try and find
> sexps
> in buffer text, doesn't seem to know what to do with this expression.
> I've spent some time staring at syntax.c, but I must confess that I'm
> entirely defeated in terms of what changes need to be made here to
> teach this other parser about prefixed strings in where the prefix
> has
> meaning that affects the interpretation of the characters between
> string fences.
> 

I've taken the suggestion Lars Ingebrigtsen made further up-thread and
implemented another draft of this using #r"" instead of r""; not only
does this not break existing elisp syntax (as noted by Po Lu earlier),
forward-sexp and backwards-sexp understand the new syntax without
having to be taught about it, to my considerable surprise. Or at least
they understand it to the same extent that they understand #s() or
#^[], anyway.

Alan (Dr. Mackenzie? Forgive me, not sure what standards are here),
your point about strings ending in \ is very well taken and I'm frankly
not sure what the easiest path forward here is. Having "raw literals
cannot end in a \" is a weird and unpleasant restriction, although the
fact that it is one that Python places on r-strings (to my considerable
surprise; I've been using Python since the mid-00s and have never run
across this particular syntax oddity before) may mean that it is
perhaps not so bad. The C++ concept of allowing r-strings to specify
their own delimiters is perhaps maximally flexible, but is definitely
going to be a heavier lift to implement than any of the above. I'd love
to hear people's opinions on the merits of the various possible
approaches here.

You've all given me a great deal of food for thought, which I will
attempt to digest before spinning a new revision of this patch.

thanks,

Anna

> I've attached a copy of my WIP patch; it's definitely not near final
> code quality and doesn't have documentation yet, all of which I would
> take care of before submitting for inclusion. I also haven't filled
> out
> the copyright assignment paperwork yet, but should this work reach a
> point where it was likely to be accepted, I'd be happy to do that.
> 
> 
> I'd very much appreciate some pointers on what to try next here, or
> some explanation of how syntax.c/syntax.el works beyond what's in the
> reference manual. If this is a fool's errand I'm tilting at here, I'd
> also appreciate being told that before I sink more time into it :)
> 
> thanks,
> 
> Anna Glasgall
> 
> 





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

* Re: "Raw" string literals for elisp
  2021-09-08 19:22         ` Philip Kaludercic
  2021-09-08 19:36           ` Alan Mackenzie
@ 2021-09-08 21:11           ` Stefan Kangas
  2021-09-08 21:24             ` Philip Kaludercic
  2021-09-09  6:52             ` tomas
  1 sibling, 2 replies; 45+ messages in thread
From: Stefan Kangas @ 2021-09-08 21:11 UTC (permalink / raw)
  To: Philip Kaludercic
  Cc: Alan Mackenzie, Emacs developers, Anna Glasgall, Stefan Monnier,
	Mattias Engdegård

Philip Kaludercic <philipk@posteo.net> writes:

> The reason I use rx in a lot of my scripts is that I can add comments,
> explanations, formatting, etc. when it gets complicated. I think that is
> a significant advantage, that even raw strings wouldn't have (unless a
> comment syntax were to be added into the regular expression language,
> which is unlikely).

Perl has this:

    perl -e '$foo = "bar"; print "yes" if $foo =~ / bar # comment /x;'

is equivalent to

    perl -e '$foo = "bar"; print "yes" if $foo =~ /bar/;'



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

* Re: "Raw" string literals for elisp
  2021-09-08 21:11           ` Stefan Kangas
@ 2021-09-08 21:24             ` Philip Kaludercic
  2021-09-09  6:52             ` tomas
  1 sibling, 0 replies; 45+ messages in thread
From: Philip Kaludercic @ 2021-09-08 21:24 UTC (permalink / raw)
  To: Stefan Kangas
  Cc: Alan Mackenzie, Emacs developers, Anna Glasgall, Stefan Monnier,
	Mattias Engdegård

Stefan Kangas <stefan@marxist.se> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> The reason I use rx in a lot of my scripts is that I can add comments,
>> explanations, formatting, etc. when it gets complicated. I think that is
>> a significant advantage, that even raw strings wouldn't have (unless a
>> comment syntax were to be added into the regular expression language,
>> which is unlikely).
>
> Perl has this:
>
>     perl -e '$foo = "bar"; print "yes" if $foo =~ / bar # comment /x;'
>
> is equivalent to
>
>     perl -e '$foo = "bar"; print "yes" if $foo =~ /bar/;'

Yes, but taking backwards compatibility into account, you cannot just
define some character to be used for comments.

-- 
	Philip Kaludercic



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

* Re: "Raw" string literals for elisp
  2021-09-08 20:40 ` Anna Glasgall
@ 2021-09-08 21:28   ` Alan Mackenzie
  0 siblings, 0 replies; 45+ messages in thread
From: Alan Mackenzie @ 2021-09-08 21:28 UTC (permalink / raw)
  To: Anna Glasgall; +Cc: emacs-devel

Hello, Anna.

On Wed, Sep 08, 2021 at 16:40:09 -0400, Anna Glasgall wrote:
> On Tue, 2021-09-07 at 21:49 -0400, Anna Glasgall wrote:

[ .... ]

> Alan (Dr. Mackenzie? Forgive me, not sure what standards are here),

Just "Alan" is fine.  No, I don't have a PhD.  :-)  Young or old, novice
or experienced, we just use first names around here.  What is unwanted is
unkind or hostile language, and curse words are not accepted at all, and
never appear.  But you don't seem like you want to write that way anyhow.
;-)

> your point about strings ending in \ is very well taken and I'm frankly
> not sure what the easiest path forward here is. Having "raw literals
> cannot end in a \" is a weird and unpleasant restriction, although the
> fact that it is one that Python places on r-strings (to my considerable
> surprise; I've been using Python since the mid-00s and have never run
> across this particular syntax oddity before) may mean that it is
> perhaps not so bad.

I think it would be bad in Emacs.  Sooner or later somebody will be
writing a regexp to match another regexp, and not being able to end in \
could be quite awkward.

Maybe giving consideration to using the C# convention of representing a "
in a raw string by "" would be advantageous.  Even this isn't entirely
simple, since a raw string with two "s in it would look something like
#r"foo""""".  From after the #r", to find the end of the raw string,
you'd have to search for the first occurrence of an odd number of
consecutive "s, which isn't entirely trivial.  It might be a rare
occurrence, but you've still got to handle it.

Or, maybe something like the python convention: #r"......""", though this
looks and feels somewhat wierd.

> The C++ concept of allowing r-strings to specify their own delimiters
> is perhaps maximally flexible, but is definitely going to be a heavier
> lift to implement than any of the above. I'd love to hear people's
> opinions on the merits of the various possible approaches here.

When implementing the C++ raw strings, that flexibility caused me a lot
of grief.  For example, changing text in the middle of a C++ raw string,
I had to check the new text didn't, by chance, form a closing delimiter
matching the opening one.  I would recommend not implementing anything
like the C++ raw string identifiers.

> You've all given me a great deal of food for thought, which I will
> attempt to digest before spinning a new revision of this patch.

> thanks,

> Anna

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).



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

* Re: "Raw" string literals for elisp
  2021-09-08 11:34 ` Adam Porter
  2021-09-08 13:59   ` Clément Pit-Claudel
@ 2021-09-09  3:09   ` Richard Stallman
  1 sibling, 0 replies; 45+ messages in thread
From: Richard Stallman @ 2021-09-09  3:09 UTC (permalink / raw)
  To: Adam Porter; +Cc: emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > #r"foo bar baz"  ;; => "foo bar baz"
    > #r|foo "bar" baz|  ;; => "foo \"bar\" baz"

To implement this, it is not enough to change the Lisp reader.
The code for parsing sexps and moving over them needs to handle
the new construct too.  With luck, maybe they will need no change,
but people have to verify that.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





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

* Re: "Raw" string literals for elisp
  2021-09-08 21:11           ` Stefan Kangas
  2021-09-08 21:24             ` Philip Kaludercic
@ 2021-09-09  6:52             ` tomas
  1 sibling, 0 replies; 45+ messages in thread
From: tomas @ 2021-09-09  6:52 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Wed, Sep 08, 2021 at 11:11:00PM +0200, Stefan Kangas wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
> 
> > The reason I use rx in a lot of my scripts is that I can add comments,
> > explanations, formatting, etc. when it gets complicated. I think that is
> > a significant advantage, that even raw strings wouldn't have (unless a
> > comment syntax were to be added into the regular expression language,
> > which is unlikely).
> 
> Perl has this:
> 
>     perl -e '$foo = "bar"; print "yes" if $foo =~ / bar # comment /x;'

Yes, Perl's "extended" regexps. They are very handy for when the concise
language is too cunfusing.

I'd tend to the position that this "ecological niche" is already (very
well) covered by `rx'. But I am aware that this is a very subjective
topic :)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

* Re: "Raw" string literals for elisp
  2021-09-08 20:18       ` Stefan Monnier
@ 2021-09-09  7:04         ` tomas
  2021-09-09 10:30         ` Mattias Engdegård
  1 sibling, 0 replies; 45+ messages in thread
From: tomas @ 2021-09-09  7:04 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

On Wed, Sep 08, 2021 at 04:18:23PM -0400, Stefan Monnier wrote:
> > I just think these are two separate dimensions which happen to align
> > in the "regexp and backslash" case.
> 
> BTW, they can align in somewhat funny ways sometimes.
> E.g. the raw-string version of the regexp "[ \t\n]" turns into something like
> 
>     #r"[
> ]"

Actually I was using "align" in a rather metaphorical sense, but you
are making a very good point: one might want to have some ot the
"classical C escapes" (\n, \r and some of its ilk, perhaps even \b),
but then `raw' wouldn't be raw anymore.

> which is not ideal in terms of clarity.  Similarly a regexp that matches
> the NUL character will be problematic when written as a raw string
> because it will need to embed the NUL character in the source code,
> which in turn will cause tools like `grep` to treat the file as binary.
> 
> For the first problem above we can/should extend our regexp syntax to
> include \t and \n as regexps that match TAB and LF respectively (that
> would also be handy when writing regexps in the minibuffer).

For regexps proper there's an escape hatch, since there is a language "on
top" that could be extended a bit (e.g. via the [:...:] character class
notation or something). But that would be unwieldy indeed.

> But \0 is already used for other things so there's no such "obvious"
> workaround for the second case :-(

Yes, the very handy `\x' notation has much history. Hard to move whithin
that cupboard without breaking anything :-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

* Re: "Raw" string literals for elisp
  2021-09-08 20:18       ` Stefan Monnier
  2021-09-09  7:04         ` tomas
@ 2021-09-09 10:30         ` Mattias Engdegård
  2021-09-09 11:36           ` Stefan Kangas
  1 sibling, 1 reply; 45+ messages in thread
From: Mattias Engdegård @ 2021-09-09 10:30 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Emacs developers

8 sep. 2021 kl. 22.18 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

> For the first problem above we can/should extend our regexp syntax to
> include \t and \n as regexps that match TAB and LF respectively (that
> would also be handy when writing regexps in the minibuffer).

Wouldn't work in character alternatives without breaking compatibility.

I've used both Perl's /x and Python's re.X in raw triple-quoted strings extensively, and they are nowhere as nice as rx.

Lisp-syntax languages really have an advantage here -- I wish I could write an equally nice DSL in other languages. Some come close.




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

* Re: "Raw" string literals for elisp
  2021-09-09 10:30         ` Mattias Engdegård
@ 2021-09-09 11:36           ` Stefan Kangas
  2021-09-09 13:33             ` Mattias Engdegård
  0 siblings, 1 reply; 45+ messages in thread
From: Stefan Kangas @ 2021-09-09 11:36 UTC (permalink / raw)
  To: Mattias Engdegård; +Cc: Stefan Monnier, Emacs developers

Mattias Engdegård <mattiase@acm.org> writes:

> I've used both Perl's /x and Python's re.X in raw triple-quoted strings extensively, and they are nowhere as nice as rx.

Agreed.  I mostly only pointed out that it exists for completion.



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

* Re: "Raw" string literals for elisp
  2021-09-09 11:36           ` Stefan Kangas
@ 2021-09-09 13:33             ` Mattias Engdegård
  2021-09-09 14:32               ` tomas
  2021-09-14 10:43               ` Augusto Stoffel
  0 siblings, 2 replies; 45+ messages in thread
From: Mattias Engdegård @ 2021-09-09 13:33 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Anna Glasgall, Stefan Monnier, Emacs developers

9 sep. 2021 kl. 13.36 skrev Stefan Kangas <stefan@marxist.se>:

>> I've used both Perl's /x and Python's re.X in raw triple-quoted strings extensively, and they are nowhere as nice as rx.
> 
> Agreed.  I mostly only pointed out that it exists for completion.

Yes, sorry -- it wasn't meant as a rebuttal to what you wrote.

It's also likely that regexps in the suggested "raw" string literals would be inferior to what Python and Perl offer for reasons Stefan Monnier already mentioned. The basic string regexp syntax would need a complete change to even come close -- and then we have two slightly different string regexp notations.

Anna, I'm ashamed for welcoming a new friendly contributor as Mr. No. In a weak attempt to compensate, here are some related areas in Emacs that might benefit from your energy and skill:

* [Easy] There is currently no build-in way to print the string " \t\r\n" exactly that way -- the best we can do (setting print-escape-newlines and print-escape-control-characters) is " \11\15\n" which isn't as readable. Introduce an option to the Lisp string printer so that common control characters print as their special backslash sequences: \t, \r, \b, \e, maybe \a and \e, maybe not \v.

* Improve interactive regexp use. Maybe a user could configure a preferred regexp syntax (standard Emacs, PCRE, rx, etc) to be used when doing interactive search and replace. It would also affect how regexps are displayed and edited in customisation dialogues; right now, they are often difficult to read. Ideally a user should be able to switch syntax during entry at any time and have the regexp translated. Can syntax colouring (font-lock) improve regexp entry and display?

I'm sure other people have more suggestions (and I have some more demanding items should you wish for something chewy.)




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

* Re: "Raw" string literals for elisp
  2021-09-09 13:33             ` Mattias Engdegård
@ 2021-09-09 14:32               ` tomas
  2021-09-14 10:43               ` Augusto Stoffel
  1 sibling, 0 replies; 45+ messages in thread
From: tomas @ 2021-09-09 14:32 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

On Thu, Sep 09, 2021 at 03:33:44PM +0200, Mattias Engdegård wrote:

[...]

> Anna, I'm ashamed for welcoming a new friendly contributor as Mr. No. In a weak attempt to compensate, here are some related areas in Emacs that might benefit from your energy and skill:

I wouldn't give up that quickly. Actually, I think this discussion
itself is invaluable, since it brings forward the issues involved
in the design of such a feature.

 - For one, as Stefan points out, you don't really want totally
   "raw" strings. Some escaping mechanism is desirable.
 - Then, it becomes clear that they will ease the biggest pain
   in regexps, but they won't "fix" everything. Some work in
   the regexp part seems desirable, too.
 - People have been looking at what other languages do. Some
   of them (e.g. Perl) let you choose the delimiter (the operators
   `q' and `qq').

There are a couple of design decisions: just "hard" raw strings, and
live with the limitation that tabs, newlines etc. are awkward? Use
an alternative escape char (e.g. tilde)? Other "crazy" ideas might
be examined ("here" documents? Perl has them, too).

The discussion comes up every now and then; even if no code ends up
being produced (I'd hope it does!) this might be a valuable resource
for the next courageous person giving it a try.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

* Re: "Raw" string literals for elisp
  2021-09-09 13:33             ` Mattias Engdegård
  2021-09-09 14:32               ` tomas
@ 2021-09-14 10:43               ` Augusto Stoffel
  2021-09-14 11:42                 ` Ihor Radchenko
  1 sibling, 1 reply; 45+ messages in thread
From: Augusto Stoffel @ 2021-09-14 10:43 UTC (permalink / raw)
  To: Mattias Engdegård
  Cc: Emacs developers, Stefan Kangas, Anna Glasgall, Stefan Monnier

On Thu,  9 Sep 2021 at 15:33, Mattias Engdegård <mattiase@acm.org> wrote:

> * Improve interactive regexp use. Maybe a user could configure a
> preferred regexp syntax (standard Emacs, PCRE, rx, etc) to be used
> when doing interactive search and replace.

IMO, interactive use is the one case where it's actually nice to have
parens etc interpreted literally by default.

> It would also affect how regexps are displayed and edited in
> customisation dialogues; right now, they are often difficult to
> read. Ideally a user should be able to switch syntax during entry at
> any time and have the regexp translated. Can syntax colouring
> (font-lock) improve regexp entry and display?

Maybe there could be a "glasses mode" for regexps, similar to the
existing one for came case?  One could display "(x)" and "\\(x\\)" in a
way that is indistinguishable except for the colors of the parenthesis.



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

* Re: "Raw" string literals for elisp
  2021-09-14 10:43               ` Augusto Stoffel
@ 2021-09-14 11:42                 ` Ihor Radchenko
  2021-09-14 13:18                   ` Stefan Monnier
  2021-09-14 17:49                   ` Jose E. Marchesi
  0 siblings, 2 replies; 45+ messages in thread
From: Ihor Radchenko @ 2021-09-14 11:42 UTC (permalink / raw)
  To: Augusto Stoffel
  Cc: Mattias Engdegård, Stefan Kangas, Anna Glasgall,
	Stefan Monnier, Emacs developers

Augusto Stoffel <arstoffel@gmail.com> writes:

> Maybe there could be a "glasses mode" for regexps, similar to the
> existing one for came case?  One could display "(x)" and "\\(x\\)" in a
> way that is indistinguishable except for the colors of the parenthesis.

And indeed there is such (on MELPA though):
https://github.com/cpitclaudel/easy-escape



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

* Re: "Raw" string literals for elisp
  2021-09-14 11:42                 ` Ihor Radchenko
@ 2021-09-14 13:18                   ` Stefan Monnier
  2021-09-14 13:22                     ` Stefan Kangas
  2021-09-14 17:49                   ` Jose E. Marchesi
  1 sibling, 1 reply; 45+ messages in thread
From: Stefan Monnier @ 2021-09-14 13:18 UTC (permalink / raw)
  To: Ihor Radchenko
  Cc: Augusto Stoffel, Mattias Engdegård, Emacs developers,
	Stefan Kangas, Anna Glasgall

>> Maybe there could be a "glasses mode" for regexps, similar to the
>> existing one for came case?  One could display "(x)" and "\\(x\\)" in a
>> way that is indistinguishable except for the colors of the parenthesis.
> And indeed there is such (on MELPA though):
> https://github.com/cpitclaudel/easy-escape

Clément signed the paperwork, so maybe we could easily add it to
GNU ELPA?


        Stefan




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

* Re: "Raw" string literals for elisp
  2021-09-14 13:18                   ` Stefan Monnier
@ 2021-09-14 13:22                     ` Stefan Kangas
  2021-09-14 14:01                       ` Ihor Radchenko
  2021-09-14 14:39                       ` Clément Pit-Claudel
  0 siblings, 2 replies; 45+ messages in thread
From: Stefan Kangas @ 2021-09-14 13:22 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: Mattias Engdegård, Ihor Radchenko, Anna Glasgall,
	Clément Pit--Claudel, Emacs developers, Augusto Stoffel

Hi Clément,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> Maybe there could be a "glasses mode" for regexps, similar to the
> >> existing one for came case?  One could display "(x)" and "\\(x\\)" in a
> >> way that is indistinguishable except for the colors of the parenthesis.
> > And indeed there is such (on MELPA though):
> > https://github.com/cpitclaudel/easy-escape
>
> Clément signed the paperwork, so maybe we could easily add it to
> GNU ELPA?

What do you think about this?



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

* Re: "Raw" string literals for elisp
  2021-09-14 13:22                     ` Stefan Kangas
@ 2021-09-14 14:01                       ` Ihor Radchenko
  2021-09-14 14:39                       ` Clément Pit-Claudel
  1 sibling, 0 replies; 45+ messages in thread
From: Ihor Radchenko @ 2021-09-14 14:01 UTC (permalink / raw)
  To: Stefan Kangas
  Cc: Mattias Engdegård, Anna Glasgall, Emacs developers,
	Clément Pit--Claudel, Stefan Monnier, Augusto Stoffel

Stefan Kangas <stefan@marxist.se> writes:

>> >> Maybe there could be a "glasses mode" for regexps, similar to the
>> >> existing one for came case?  One could display "(x)" and "\\(x\\)" in a
>> >> way that is indistinguishable except for the colors of the parenthesis.
>> > And indeed there is such (on MELPA though):
>> > https://github.com/cpitclaudel/easy-escape
>>
>> Clément signed the paperwork, so maybe we could easily add it to
>> GNU ELPA?

Sounds like a good idea. I asked the author on Github [1].

[1] https://github.com/cpitclaudel/easy-escape/issues/5



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

* Re: "Raw" string literals for elisp
  2021-09-14 13:22                     ` Stefan Kangas
  2021-09-14 14:01                       ` Ihor Radchenko
@ 2021-09-14 14:39                       ` Clément Pit-Claudel
  2021-09-14 15:33                         ` Amin Bandali
  2021-09-14 16:05                         ` Eli Zaretskii
  1 sibling, 2 replies; 45+ messages in thread
From: Clément Pit-Claudel @ 2021-09-14 14:39 UTC (permalink / raw)
  To: Stefan Kangas, Stefan Monnier
  Cc: Mattias Engdegård, Augusto Stoffel, Ihor Radchenko,
	Anna Glasgall, Emacs developers

On 9/14/21 9:22 AM, Stefan Kangas wrote:
> Hi Clément,
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>>> Maybe there could be a "glasses mode" for regexps, similar to the
>>>> existing one for came case?  One could display "(x)" and "\\(x\\)" in a
>>>> way that is indistinguishable except for the colors of the parenthesis.
>>> And indeed there is such (on MELPA though):
>>> https://github.com/cpitclaudel/easy-escape
>>
>> Clément signed the paperwork, so maybe we could easily add it to
>> GNU ELPA?
> 
> What do you think about this?

Sounds good to me; please feel free to add it to ELPA (I would prefer core, but the last thread on this topic flopped: https://lists.gnu.org/archive/html/emacs-devel/2017-03/msg00266.html).



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

* Re: "Raw" string literals for elisp
  2021-09-14 14:39                       ` Clément Pit-Claudel
@ 2021-09-14 15:33                         ` Amin Bandali
  2021-09-14 16:05                         ` Eli Zaretskii
  1 sibling, 0 replies; 45+ messages in thread
From: Amin Bandali @ 2021-09-14 15:33 UTC (permalink / raw)
  To: Clément Pit-Claudel
  Cc: Mattias Engdegård, Stefan Kangas, Anna Glasgall,
	Ihor Radchenko, Stefan Monnier, Emacs developers,
	Augusto Stoffel

Clément Pit-Claudel writes:

> On 9/14/21 9:22 AM, Stefan Kangas wrote:
>> Hi Clément,
>> 
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 
>>>>> Maybe there could be a "glasses mode" for regexps, similar to the
>>>>> existing one for came case?  One could display "(x)" and "\\(x\\)" in a
>>>>> way that is indistinguishable except for the colors of the parenthesis.
>>>> And indeed there is such (on MELPA though):
>>>> https://github.com/cpitclaudel/easy-escape
>>>
>>> Clément signed the paperwork, so maybe we could easily add it to
>>> GNU ELPA?
>> 
>> What do you think about this?
>
> Sounds good to me; please feel free to add it to ELPA (I would prefer
> core, but the last thread on this topic flopped:
> https://lists.gnu.org/archive/html/emacs-devel/2017-03/msg00266.html).

Thanks, Clément.  I'd also very much like to see this in core.



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

* Re: "Raw" string literals for elisp
  2021-09-14 14:39                       ` Clément Pit-Claudel
  2021-09-14 15:33                         ` Amin Bandali
@ 2021-09-14 16:05                         ` Eli Zaretskii
  1 sibling, 0 replies; 45+ messages in thread
From: Eli Zaretskii @ 2021-09-14 16:05 UTC (permalink / raw)
  To: Clément Pit-Claudel
  Cc: mattiase, stefan, anna, yantar92, monnier, emacs-devel, arstoffel

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Tue, 14 Sep 2021 10:39:52 -0400
> Cc: Mattias Engdegård <mattiase@acm.org>,
>  Augusto Stoffel <arstoffel@gmail.com>, Ihor Radchenko <yantar92@gmail.com>,
>  Anna Glasgall <anna@crossproduct.net>, Emacs developers <emacs-devel@gnu.org>
> Sounds good to me; please feel free to add it to ELPA (I would prefer core, but the last thread on this topic flopped: https://lists.gnu.org/archive/html/emacs-devel/2017-03/msg00266.html).

FWIW, it makes very little sense to me to have only on ELPA code that
adds a new Emacs Lisp data type.



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

* Re: "Raw" string literals for elisp
  2021-09-14 11:42                 ` Ihor Radchenko
  2021-09-14 13:18                   ` Stefan Monnier
@ 2021-09-14 17:49                   ` Jose E. Marchesi
  1 sibling, 0 replies; 45+ messages in thread
From: Jose E. Marchesi @ 2021-09-14 17:49 UTC (permalink / raw)
  To: Ihor Radchenko
  Cc: Mattias Engdegård, Stefan Kangas, Anna Glasgall,
	Emacs developers, Stefan Monnier, Augusto Stoffel


> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>> Maybe there could be a "glasses mode" for regexps, similar to the
>> existing one for came case?  One could display "(x)" and "\\(x\\)" in a
>> way that is indistinguishable except for the colors of the parenthesis.
>
> And indeed there is such (on MELPA though):
> https://github.com/cpitclaudel/easy-escape

This is awesome.



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

end of thread, other threads:[~2021-09-14 17:49 UTC | newest]

Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-08  1:49 "Raw" string literals for elisp Anna Glasgall
2021-09-08  7:10 ` Po Lu
2021-09-08 14:19   ` Anna Glasgall
2021-09-08  7:12 ` Lars Ingebrigtsen
2021-09-08 14:20   ` Anna Glasgall
2021-09-08 11:30 ` Alan Mackenzie
2021-09-08 14:27   ` Anna Glasgall
2021-09-08 11:34 ` Adam Porter
2021-09-08 13:59   ` Clément Pit-Claudel
2021-09-08 14:12     ` Adam Porter
2021-09-09  3:09   ` Richard Stallman
2021-09-08 13:10 ` Stefan Monnier
2021-09-08 14:31   ` Anna Glasgall
2021-09-08 15:27     ` Mattias Engdegård
2021-09-08 15:41       ` Stefan Kangas
2021-09-08 16:45         ` Mattias Engdegård
2021-09-08 16:01       ` Alan Mackenzie
2021-09-08 18:24         ` Mattias Engdegård
2021-09-08 19:00           ` Alan Mackenzie
2021-09-08 19:22         ` Philip Kaludercic
2021-09-08 19:36           ` Alan Mackenzie
2021-09-08 21:11           ` Stefan Kangas
2021-09-08 21:24             ` Philip Kaludercic
2021-09-09  6:52             ` tomas
2021-09-08 15:54     ` Stefan Kangas
2021-09-08 16:05     ` tomas
2021-09-08 16:42       ` Lars Ingebrigtsen
2021-09-08 20:08         ` Stefan Monnier
2021-09-08 20:18       ` Stefan Monnier
2021-09-09  7:04         ` tomas
2021-09-09 10:30         ` Mattias Engdegård
2021-09-09 11:36           ` Stefan Kangas
2021-09-09 13:33             ` Mattias Engdegård
2021-09-09 14:32               ` tomas
2021-09-14 10:43               ` Augusto Stoffel
2021-09-14 11:42                 ` Ihor Radchenko
2021-09-14 13:18                   ` Stefan Monnier
2021-09-14 13:22                     ` Stefan Kangas
2021-09-14 14:01                       ` Ihor Radchenko
2021-09-14 14:39                       ` Clément Pit-Claudel
2021-09-14 15:33                         ` Amin Bandali
2021-09-14 16:05                         ` Eli Zaretskii
2021-09-14 17:49                   ` Jose E. Marchesi
2021-09-08 20:40 ` Anna Glasgall
2021-09-08 21:28   ` Alan Mackenzie

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

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 NNTP newsgroup(s).