GNU bug report logs - #62224
30.0.50: Emacs don't, start sends an erroneous error

Previous Next

Full log

View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: Andreas Röhler <andreas.roehler <at> easy-emacs.de>, 62224 <at> debbugs.gnu.org
Subject: bug#62224: 30.0.50: Emacs don't, start sends an erroneous error
Date: Thu, 16 Mar 2023 11:45:40 -0700

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.