bug#23867: 25.1.50; Doc string containing `\N'

bug#23867: 25.1.50; Doc string containing `\N'

[Tino Calancha]

After commit
de7d5f36e0f3261a7300fa3a3d87ae3b758b8a73
a doc string cannot contain `\N'.  It should be
written `\\N'.

For instance:
emacs -Q
;; create a file foo.el with contents:

(defun foo ()
   "Test characters allowed in doc strings.
The following char is not allowed: `\N'
You need to double the slash."
   (interactive)
   (message "Test for doc strings"))

;; Load the file:
;; invalid-read-syntax Expected opening brace after \N

I saw 3rd party code with doc strings containing `\N'.
Should that 3rd party code update to `\\N'?
Or is OK to allow doc strings with `\N'?


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
diff --git a/src/lread.c b/src/lread.c
index 5c47f78..7643d49 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -2390,6 +2390,8 @@ read_escape (Lisp_Object readcharfun, bool stringp)
        /* Named character.  */
        {
          c = READCHAR;
+        if (c == '\'')
+          return c;
          if (c != '{')
            invalid_syntax ("Expected opening brace after \\N");
          char name[UNICODE_CHARACTER_NAME_LENGTH_BOUND + 1];


GNU Emacs 25.1.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.20.6) of 
2016-06-29
Repository revision: 4a2a1eba09e5bbc37b853733708feae17f1425f5

bug#23867: 25.1.50; Doc string containing `\N'

[Andreas Schwab]

Tino Calancha <tino.calancha@gmail.com> writes:

> After commit
> de7d5f36e0f3261a7300fa3a3d87ae3b758b8a73
> a doc string cannot contain `\N'.

Before that "\N" was the same as "N", so there is no point in writing
that.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#23867: 25.1.50; Doc string containing `\N'

[Tino Calancha]

On Wed, 29 Jun 2016, Andreas Schwab wrote:

> Before that "\N" was the same as "N", so there is no point in writing
> that.
Good point.  Thank you.

Tino

bug#23867: 25.1.50; Doc string containing `\N'

[Drew Adams]

> > Before that "\N" was the same as "N", so there is no point in writing
> > that.
>
> Good point.  Thank you.

It's a valid point, but it is also wrong.

There might be "no point in writing" \N, but there can be a use
for having \N act as N - as it always has.  Doc strings can be
produced by _code_, and that code can escape ordinary characters,
for which the escaping should be a no-op.

There have been very few exceptions to this in the past - very
few characters for which \-escaping is not a no-op.  What's the
rationale for breaking this for N?

bug#23867: 25.1.50; Doc string containing `\N'

[Andreas Schwab]

Drew Adams <drew.adams@oracle.com> writes:

> There have been very few exceptions to this in the past - very
> few characters for which \-escaping is not a no-op.  What's the
> rationale for breaking this for N?

The same as for `u' or `U' or ` ' or `x' (in reverse chronological
order).

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#23867: 25.1.50; Doc string containing `\N'

[Noam Postavsky]

On Wed, Jun 29, 2016 at 10:00 AM, Drew Adams <drew.adams@oracle.com> wrote:
>
> There have been very few exceptions to this in the past - very
> few characters for which \-escaping is not a no-op.  What's the
> rationale for breaking this for N?

It's in NEWS:

** Emacs now supports character name escape sequences in character and
string literals.  The syntax variants \N{character name} and
\N{U+code} are supported.

bug#23867: 25.1.50; Doc string containing `\N'

[Glenn Morris]

Tino Calancha wrote:

> ;; invalid-read-syntax Expected opening brace after \N

Is it too difficult for \N followed by anything other than { to be
treated (possibly with a warning?) as before (ie, not as an escape)?
Then cake can be had and eaten.

bug#23867: 25.1.50; Doc string containing `\N'

[Paul Eggert]

> Is it too difficult for \N followed by anything other than { to be
> treated (possibly with a warning?) as before (ie, not as an escape)?

It could be done, but I'd rather not. lread.c doesn't warn about other 
stuff, by and large, and any warnings are likely to be ignored anyway. 
It would be additional complexity for very little benefit.

As a general rule Elisp code should not use \X unless \X is documented 
to be part of an escape sequence, or X is an ASCII punctuation character 
that might otherwise confuse Emacs. (By the way, are the punctuation 
characters still an issue? I've forgotten what their problem was or is.)

bug#23867: 25.1.50; Doc string containing `\N'

[Glenn Morris]

Paul Eggert wrote:

>> Is it too difficult for \N followed by anything other than { to be
>> treated (possibly with a warning?) as before (ie, not as an escape)?
>
> It could be done, but I'd rather not. lread.c doesn't warn about other
> stuff, by and large, and any warnings are likely to be ignored anyway.
> It would be additional complexity for very little benefit.

Fair enough.
I will close this report then.