bug#62224: 30.0.50: Emacs don't, start sends an erroneous error

bug#62224: 30.0.50: Emacs don't, start sends an erroneous error

[Andreas Röhler]

Emacs don't start sending an erroneous error, backtrace at the end of 
this report.

Error points to the docstring of the function below, notably at the 
escaped ‘x’:

---
(defun lean-input-compose (f g)
   "\x -> concatMap F (G x)"
   (lexical-let ((f1 f) (g1 g))
     (lambda (x) (lean-input-concat-map f1 (funcall g1 x)))))
---

Debugger entered--Lisp error: (error "Invalid escape character syntax")
   read(#<buffer  *load*-183932>)
   eval-buffer(#<buffer  *load*-183932> nil 
"/home/my-name/.emacs.d/straight/build/lean-mode/lean..." nil t) ; 
Reading at buffer position 2036
load-with-code-conversion("/home/my-name/.emacs.d/straight/build/lean-mode/lean..." 
"/home/my-name/.emacs.d/straight/build/lean-mode/lean-input.el" nil t)
   require(lean-input)
   eval-buffer(#<buffer  *load*-311253> nil 
"/home/my-name/.emacs.d/straight/build/lean-mode/lean..." nil t) ; 
Reading at buffer position 1185
load-with-code-conversion("/home/my-name/.emacs.d/straight/build/lean-mode/lean..." 
"/home/my-name/.emacs.d/straight/build/lean-mode/lean..." nil t)
   require(lean-mode)
   eval-buffer(#<buffer  *load*-80552> nil "/home/my-name/.gnu-emacs25" 
nil t)  ; Reading at buffer position 10520
   load-with-code-conversion("/home/my-name/.gnu-emacs25" 
"/home/my-name/.gnu-emacs25" nil nil)
   load("/home/my-name/.gnu-emacs25")
   (cond ((string-match "^23" emacs-version) (setq custom-file 
(expand-file-name "~/.gnu-emacs23-cvs-custom")) (load (expand-file-name 
"~/.gnu-emacs23-all-cvs"))) ((string-match "^24" emacs-version) (setq 
custom-file (expand-file-name "~/.gnu-emacs24-custom")) (load 
(expand-file-name "~/.gnu-emacs24"))) (t (setq custom-file 
(expand-file-name "~/.gnu-emacs25-custom")) (load (expand-file-name 
"~/.gnu-emacs25"))))
   eval-buffer(#<buffer  *load*> nil "/home/my-name/.emacs" nil t)  ; 
Reading at buffer position 840
   load-with-code-conversion("/home/my-name/.emacs" 
"/home/my-name/.emacs" t t)
   load("~/.emacs" noerror nomessage)
   startup--load-user-init-file(#f(compiled-function () #<bytecode 
-0x19c7dbe75dab1fbb>) #f(compiled-function () #<bytecode 
-0x1f3c61addc0bc175>) t)
   command-line()
   normal-top-level()


GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.16.0) of 2023-03-16

bug#62224: 30.0.50: Emacs don't, start sends an erroneous error

[Jim Porter]

On 3/16/2023 11:08 AM, Andreas Röhler wrote:
> Emacs don't start sending an erroneous error, backtrace at the end of 
> this report.
> 
> Error points to the docstring of the function below, notably at the 
> escaped ‘x’:
> 
> ---
> (defun lean-input-compose (f g)
>    "\x -> concatMap F (G x)"
>    (lexical-let ((f1 f) (g1 g))
>      (lambda (x) (lean-input-concat-map f1 (funcall g1 x)))))
> ---

In Emacs Lisp, "\x" is the start of a hexadecimal character escape, like 
"\x41" for "A". In Emacs 29, just a plain "\x" was treated as NUL, but 
in Emacs 30, this is now a syntax error. I think that makes sense, since 
it helps catch likely mistakes such as this one.

That said, I think *technically* the manual says that "\x" is allowed:

> You can use any number of hex digits, so you can represent any
> character code in this way.

Zero is a number, after all. :) Maybe the manual needs an update to be 
more-precise here?

Ultimately, I think this is a bug in lean-mode though. I don't know 
anything about Lean in particular, but I think the docstring above is 
trying to use the backslash literally, rather than as an escape introducer.

bug#62224: 30.0.50: Emacs don't, start sends an erroneous error

[Eli Zaretskii]

> Date: Thu, 16 Mar 2023 11:45:40 -0700
> From: Jim Porter <jporterbugs@gmail.com>
> 
> That said, I think *technically* the manual says that "\x" is allowed:
> 
> > You can use any number of hex digits, so you can represent any
> > character code in this way.
> 
> Zero is a number, after all. :) Maybe the manual needs an update to be 
> more-precise here?

I'd say that'd be a pedantic interpretation of the text, but I've
reworded it to avoid such misinterpretation anyway.

bug#62224: 30.0.50: Emacs don't, start sends an erroneous error

[Jim Porter]

On 3/16/2023 1:07 PM, Eli Zaretskii wrote:
>> Date: Thu, 16 Mar 2023 11:45:40 -0700
>> From: Jim Porter <jporterbugs@gmail.com>
>>
>> That said, I think *technically* the manual says that "\x" is allowed:
>>
>>> You can use any number of hex digits, so you can represent any
>>> character code in this way.
>>
>> Zero is a number, after all. :) Maybe the manual needs an update to be
>> more-precise here?
> 
> I'd say that'd be a pedantic interpretation of the text, but I've
> reworded it to avoid such misinterpretation anyway.

Oh, it's very pedantic, I agree. I'm not sure anyone would have 
misinterpreted that text in practice, but I think this makes it 100% 
clear what syntax is acceptable. Thanks for the fix.

bug#62224: 30.0.50: Emacs don't, start sends an erroneous error

[Andreas Röhler]

Assume it's just lean-syntax in the case given.

IMO Emacs should not care for stuff inside documentation strings.


Am 16.03.23 um 21:31 schrieb Jim Porter:
> On 3/16/2023 1:07 PM, Eli Zaretskii wrote:
>>> Date: Thu, 16 Mar 2023 11:45:40 -0700
>>> From: Jim Porter <jporterbugs@gmail.com>
>>>
>>> That said, I think *technically* the manual says that "\x" is allowed:
>>>
>>>> You can use any number of hex digits, so you can represent any
>>>> character code in this way.
>>>
>>> Zero is a number, after all. :) Maybe the manual needs an update to be
>>> more-precise here?
>>
>> I'd say that'd be a pedantic interpretation of the text, but I've
>> reworded it to avoid such misinterpretation anyway.
>
> Oh, it's very pedantic, I agree. I'm not sure anyone would have 
> misinterpreted that text in practice, but I think this makes it 100% 
> clear what syntax is acceptable. Thanks for the fix.

bug#62224: 30.0.50: Emacs don't, start sends an erroneous error

[Eli Zaretskii]

> Date: Sat, 18 Mar 2023 09:10:18 +0100
> Cc: 62224@debbugs.gnu.org
> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
> 
> IMO Emacs should not care for stuff inside documentation strings.

We decided it should, because errors like this one produce incorrect
and confusing doc strings.