bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[No Wayman]

From the body of pp--insert-lisp in pp.el:


```emacs-lisp
;; Print some of the smaller integers as characters, perhaps?
(integer
 (if (<= ?0 sexp ?z)
     (let ((print-integers-as-characters t))
       (princ sexp (current-buffer)))
   (princ sexp (current-buffer))))
```

I stumbled on this behavior in a program of which pretty prints 
elisp forms as part of a report.
I don't want characters when the input form originally included 
integers.
Why do we do this here? The commentary doesn't offer any insight 
and sounds confused about the behavior, too.
Is it worth making configurable, or outright removing?

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[No Wayman]

No Wayman <iarchivedmywholelife@gmail.com> writes:

> From the body of pp--insert-lisp in pp.el:
>
>
> ```emacs-lisp
> ;; Print some of the smaller integers as characters, perhaps?
> (integer
> (if (<= ?0 sexp ?z)
>     (let ((print-integers-as-characters t))
>       (princ sexp (current-buffer)))
>   (princ sexp (current-buffer))))
> ```
>
> I stumbled on this behavior in a program of which pretty prints 
> elisp forms as
> part of a report.
> I don't want characters when the input form originally included 
> integers.
> Why do we do this here? The commentary doesn't offer any insight 
> and sounds
> confused about the behavior, too.
> Is it worth making configurable, or outright removing?

A side-effect that tilts me in favor of removing said behavior:

$ emacs -q --batch --eval '(pp-emacs-lisp-code `(:comments 59))' 

Error: scan-error ("Unbalanced parentheses" 1 16)
  forward-sexp-default-function(1)
  forward-sexp(1)
  indent-sexp()
  pp-emacs-lisp-code((:comments 59))
  eval((pp-emacs-lisp-code `(:comments 59)) t)
  command-line-1(("--eval" "(pp-emacs-lisp-code `(:comments 
  59))"))
  command-line()
  normal-top-level()
Scan error: "Unbalanced parentheses", 1, 16

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[Eli Zaretskii]

> From: No Wayman <iarchivedmywholelife@gmail.com>
> Date: Fri, 10 May 2024 20:10:43 -0400
> 
> No Wayman <iarchivedmywholelife@gmail.com> writes:
> 
> > From the body of pp--insert-lisp in pp.el:
> >
> >
> > ```emacs-lisp
> > ;; Print some of the smaller integers as characters, perhaps?
> > (integer
> > (if (<= ?0 sexp ?z)
> >     (let ((print-integers-as-characters t))
> >       (princ sexp (current-buffer)))
> >   (princ sexp (current-buffer))))
> > ```
> >
> > I stumbled on this behavior in a program of which pretty prints 
> > elisp forms as
> > part of a report.
> > I don't want characters when the input form originally included 
> > integers.
> > Why do we do this here? The commentary doesn't offer any insight 
> > and sounds
> > confused about the behavior, too.
> > Is it worth making configurable, or outright removing?
> 
> A side-effect that tilts me in favor of removing said behavior:
> 
> $ emacs -q --batch --eval '(pp-emacs-lisp-code `(:comments 59))' 
> 
> Error: scan-error ("Unbalanced parentheses" 1 16)
>   forward-sexp-default-function(1)
>   forward-sexp(1)
>   indent-sexp()
>   pp-emacs-lisp-code((:comments 59))
>   eval((pp-emacs-lisp-code `(:comments 59)) t)
>   command-line-1(("--eval" "(pp-emacs-lisp-code `(:comments 
>   59))"))
>   command-line()
>   normal-top-level()
> Scan error: "Unbalanced parentheses", 1, 16

Lars and Stefan, any comments?

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

No Wayman <iarchivedmywholelife@gmail.com> writes:

> From the body of pp--insert-lisp in pp.el:
>
> ```emacs-lisp
> ;; Print some of the smaller integers as characters, perhaps?
> (integer
>  (if (<= ?0 sexp ?z)
>      (let ((print-integers-as-characters t))
>        (princ sexp (current-buffer)))
>    (princ sexp (current-buffer))))
> ```
>
> I stumbled on this behavior in a program of which pretty prints
> elisp forms as part of a report.
> I don't want characters when the input form originally included
> integers.
> Why do we do this here? The commentary doesn't offer any insight
> and sounds confused about the behavior, too.

No, this had been done intentionally of course - and AFAIU, the comment
only asks whether to include even more characters.

The code currently guesses which syntax is more likely to be satisfying.

> Is it worth making configurable, or outright removing?

We could make it configurable, but note that this will not avoid this
kind of problem: one and the same expression can include numbers in that
range that are "meant" as characters and others that are "meant" as
integers.  Characters being printed as integers is likewise annoying as
the opposite problem.

Anyway, adding a user option will probably be the best solution we can
implement.

Michael.

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

No Wayman <iarchivedmywholelife@gmail.com> writes:

> $ emacs -q --batch --eval '(pp-emacs-lisp-code `(:comments 59))'
> Error: scan-error ("Unbalanced parentheses" 1 16)
>  forward-sexp-default-function(1)
>  forward-sexp(1)
>  indent-sexp()
>  pp-emacs-lisp-code((:comments 59))
>  eval((pp-emacs-lisp-code `(:comments 59)) t)
>  command-line-1(("--eval" "(pp-emacs-lisp-code `(:comments   59))"))
>  command-line()
>  normal-top-level()
> Scan error: "Unbalanced parentheses", 1, 16

A good catch!  59 is the character ;.  This is a bug in the printer:

#+begin_src emacs-lisp
(let ((print-integers-as-characters t))
   (princ ?\; (current-buffer)))
#+end_src

prints "?;" instead of "?\;" - it fails to quote the character.  Binding
`print-quoted' doesn't help.  This needs to be fixed.


Michael.

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hello,

I guess Mattias is the right one to CC for this problem.

> > $ emacs -q --batch --eval '(pp-emacs-lisp-code `(:comments 59))'
> > Error: scan-error ("Unbalanced parentheses" 1 16)
> >  forward-sexp-default-function(1)
> >  forward-sexp(1)
> >  indent-sexp()
> >  pp-emacs-lisp-code((:comments 59))
> >  eval((pp-emacs-lisp-code `(:comments 59)) t)
> >  command-line-1(("--eval" "(pp-emacs-lisp-code `(:comments   59))"))
> >  command-line()
> >  normal-top-level()
> > Scan error: "Unbalanced parentheses", 1, 16
>
> A good catch!  59 is the character ;.  This is a bug in the printer:
>
> #+begin_src emacs-lisp
> (let ((print-integers-as-characters t))
>    (princ ?\; (current-buffer)))
> #+end_src
>
> prints "?;" instead of "?\;" - it fails to quote the character.  Binding
> `print-quoted' doesn't help.  This needs to be fixed.


Michael.

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[Andreas Schwab]

On Mai 11 2024, Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> A good catch!  59 is the character ;.  This is a bug in the printer:
>
> #+begin_src emacs-lisp
> (let ((print-integers-as-characters t))
>    (princ ?\; (current-buffer)))
> #+end_src
>
> prints "?;" instead of "?\;" - it fails to quote the character.  Binding
> `print-quoted' doesn't help.  This needs to be fixed.

princ does not add any quoting, you need to use prin1 instead.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[Mattias Engdegård]

11 maj 2024 kl. 13.09 skrev Michael Heerdegen <michael_heerdegen@web.de>:

> (let ((print-integers-as-characters t))
>   (princ ?\; (current-buffer)))
> 
> prints "?;" instead of "?\;" - it fails to quote the character.  Binding
> `print-quoted' doesn't help.  This needs to be fixed.

Does it? Not defending the code in any way, but `princ` isn't supposed to quote anything. If you want it in a form that can be read back in, use `prin1`.

We do get to make up the rules, though. Perhaps it should print 57 as `;` instead of `?;`. It's not clear what makes the most sense here.

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 11 maj 2024 kl. 13.09 skrev Michael Heerdegen <michael_heerdegen@web.de>:
>
> > (let ((print-integers-as-characters t))
> >   (princ ?\; (current-buffer)))
> > 
> > prints "?;" instead of "?\;" - it fails to quote the character.  Binding
> > `print-quoted' doesn't help.  This needs to be fixed.
>
> Does it? Not defending the code in any way, but `princ` isn't supposed
> to quote anything. If you want it in a form that can be read back in,
> use `prin1`.
>
> We do get to make up the rules, though. Perhaps it should print 57 as
> `;` instead of `?;`. It's not clear what makes the most sense here.

Thanks Andreas and Mattias for bringing up the missing point.

I don't have an opinion about - and don't want to answer - what `princ'
should print here, and rather stick to original problem of this bug
report.

It is quite obvious that we need to change `pp--insert-lisp' to use
`prin1' in this case - again: we changed several other places in the
past in the same way.

Does anyone have a clue if there is a reason why we should not simply
change _all_ occurrences of `princ' to `prin1' in `pp--insert-lisp' and
related functions?  It seems that when there is a difference we always
want `prin1', i.e. readable, printing.

BTW, is there a rule of thumb that makes it possible to remember which
of the two does the readable printing?  I'm always confusing them or
even don't get the problem.


Thanks,

Michael.

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[Mattias Engdegård]

11 maj 2024 kl. 16.48 skrev Michael Heerdegen <michael_heerdegen@web.de>:

> Does anyone have a clue if there is a reason why we should not simply
> change _all_ occurrences of `princ' to `prin1' in `pp--insert-lisp' and
> related functions?

Those in `pp--insert-lisp` should probably be `prin1`. (Don't change the one in `pp`.)

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs@gnu.org> writes:

> > Is it worth making configurable, or outright removing?
>
> We could make it configurable, but note that this will not avoid this
> kind of problem: one and the same expression can include numbers in that
> range that are "meant" as characters and others that are "meant" as
> integers.  Characters being printed as integers is likewise annoying as
> the opposite problem.
>
> Anyway, adding a user option will probably be the best solution we can
> implement.

We already have `print-integers-as-characters', though.  So if we want to
make this completely controllable on the per usage basis, removing those
lines would indeed make more sense.  Then the user could just bind
`print-integers-as-characters' as for any other printing action.


Another thought: In a lot of cases the user specifies code in an already
printed form - either at a (e.g. the M-:) prompt as a function argument,
or the code is present in a buffer or file.  And the user just wants to
have it prettified.  Then we `read' it, losing all syntactical
distinctions and redundancies, and guess what syntax might be
appropriate although we just threw that information away.

Doing it differently would mean to write something new that would
operate on strings or buffer text instead of printing expressions.
AFAIR, some the pp functions already do that but on a very simple level
(like adding newlines and indentation).


Michael.

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[Eli Zaretskii]

> Cc: iarchivedmywholelife@gmail.com
> Date: Sat, 11 May 2024 18:38:48 +0200
> From:  Michael Heerdegen via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> > Anyway, adding a user option will probably be the best solution we can
> > implement.
> 
> We already have `print-integers-as-characters', though.  So if we want to
> make this completely controllable on the per usage basis, removing those
> lines would indeed make more sense.  Then the user could just bind
> `print-integers-as-characters' as for any other printing action.

The issue here is user expectations from what Emacs does by default.
To see what I mean, remove those lines, and then try

  M-: (pp-emacs-lisp-code '(eq foo ?a)) RET

Evidently, there are two sides to this coin.

bug#70868: 30.0.50;

[iarchivedmywholelife]

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

I would expect/want no conversion in either case. Maybe instead of printing based purely off type we can see what how the data was represented and delegate based off that. 
-------- Original message --------From: Eli Zaretskii <eliz@gnu.org> Date: 5/11/24  12:47 PM  (GMT-05:00) To: Michael Heerdegen <michael_heerdegen@web.de> Cc: 70868@debbugs.gnu.org, iarchivedmywholelife@gmail.com Subject: Re: bug#70868: 30.0.50; > Cc: iarchivedmywholelife@gmail.com> Date: Sat, 11 May 2024 18:38:48 +0200> From:  Michael Heerdegen via "Bug reports for GNU Emacs,>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>> > > Anyway, adding a user option will probably be the best solution we can> > implement.> > We already have `print-integers-as-characters', though.  So if we want to> make this completely controllable on the per usage basis, removing those> lines would indeed make more sense.  Then the user could just bind> `print-integers-as-characters' as for any other printing action.The issue here is user expectations from what Emacs does by default.To see what I mean, remove those lines, and then try  M-: (pp-emacs-lisp-code '(eq foo ?a)) RETEvidently, there are two sides to this coin.

[-- Attachment #2: Type: text/html, Size: 1648 bytes --]

bug#70868: 30.0.50;

[Eli Zaretskii]

> Date: Sat, 11 May 2024 14:26:07 -0400
> From: iarchivedmywholelife <iarchivedmywholelife@gmail.com>
> Cc: 70868@debbugs.gnu.org
> 
> I would expect/want no conversion in either case.

Then you are basically talking about a very different implementation.
As long as the implementation 'read's the SEXP argument, you cannot
expect no conversion.

bug#70868: 30.0.50;

[Eli Zaretskii]

> Cc: michael_heerdegen@web.de, 70868@debbugs.gnu.org
> Date: Sat, 11 May 2024 21:29:11 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sat, 11 May 2024 14:26:07 -0400
> > From: iarchivedmywholelife <iarchivedmywholelife@gmail.com>
> > Cc: 70868@debbugs.gnu.org
> > 
> > I would expect/want no conversion in either case.
> 
> Then you are basically talking about a very different implementation.
> As long as the implementation 'read's the SEXP argument, you cannot
> expect no conversion.

Here's a very simple example, unrelated to numbers vs characters:

  M-: (pp-emacs-lisp-code '((quote a))) RET
    => ('a)

bug#70868: 30.0.50;

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>   M-: (pp-emacs-lisp-code '((quote a))) RET
>     => ('a)

Another one is nil vs. () or '() vs. 'nil, like in

  (defun f () ...)  vs.  (defun f nil ...)

or

  (delq nil my-list) vs. (delq () my-list)

etc, then - when to use dot syntax? - there is
`(foo . (,b)) vs. `(foo ,b) or

(let ((my-alist '((a . (1 2)) (b . (3 4))))) ...) vs.
(let ((my-alist '((a 1 2))    (b 3 4))) ...)

then (list +1 -1) vs. (list 1 -1), ?c vs. n vs ?\x... vs. ?\N...,
then there is "\n" vs "
" (docstrings!!!) - there is a ton of such ambiguities!

And note that we have only brought up silly one-line code examples so
far.  In real code, what the user expects will be _different_ for
different places in one and the same larger expression.

I totally agree that this problem is surprising and APITA, but please
don't expect that `pp-emacs-lisp-code' will ever produce satisfying
results when fed with existing code written by humans (i.e., when we
`read' and reprint it).  This will mess up as much as it prettifies, and
more.

And note there are even more problems of other kinds.  Another one is
that we don't discriminate context dependent semantics.  Is (let ...) a
`let' expression?  Or a `let' `pcase' form?  Or a list of names of
special forms?  Or maybe something which is meant to be macroexpanded to
a `let' expression, and the second element of the list is not a binding
list but something like ,(compute-let-bindings)?


I know these kinds of problems well and for years from my experience
with my "el-search" package - when I first tried an automatic rewriting
rule like

   `(if ,cond ,form) --> `(when ,cond ,form)

I was very disappointed about how ugly everything got when all in FORM
got folded to syntactical defaults.

[ For completion, if anyone wonders: in "el-search" I try to identify
the code parts that get part of the replacement expression - COND and
FORM in the above example - in the original code in the buffer operated
on and reuse the print syntax from there. ]


In sum I'm quite sure that

  M-: (pp--insert-lisp 'my-large-thunk-of-real-life-code)

is something that will never produce really good looking code whatever
guessing and heuristical cleverness we might be able to invent.  It will
always produce a result that a human will have to tune and correct
manually line by line.  Which is actually exactly the work we wanted to
delegate to this function!


So, my opinion is that Elisp pretty printing with input expressions, in
contrast to text, is, if at all, only useful for automatically generated
expressions (like macro expansions).  It's trivial that this will come
with the same problems (though in this case they are a bit less
surprising and annoying at least).  We should still fix this bug,
obviously.


Michael.

bug#70868: 30.0.50;

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: iarchivedmywholelife@gmail.com,  70868@debbugs.gnu.org
> Date: Sun, 12 May 2024 16:50:40 +0200
> 
> So, my opinion is that Elisp pretty printing with input expressions, in
> contrast to text, is, if at all, only useful for automatically generated
> expressions (like macro expansions).

I think if we want a Lisp formatter that is free of these issues, we
need to implement a bona-fide formatter, which reindents and reformats
Lisp code without actually 'read'ing and interpreting it.

> We should still fix this bug, obviously.

If you are talking about the bug with 59, then Mattias suggested to
exempt the semi-colon from the "display-small-numbers-as-characters"
feature.

bug#70868: 30.0.50;

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> I think if we want a Lisp formatter that is free of these issues, we
> need to implement a bona-fide formatter, which reindents and reformats
> Lisp code without actually 'read'ing and interpreting it.

+1

> > We should still fix this bug, obviously.
>
> If you are talking about the bug with 59, then Mattias suggested to
> exempt the semi-colon from the "display-small-numbers-as-characters"
> feature.

Yes - but independent of that I think we want to switch printing using
`prin1'.


Michael.

bug#70868: 30.0.50;

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: iarchivedmywholelife@gmail.com,  70868@debbugs.gnu.org
> Date: Sun, 12 May 2024 17:15:30 +0200
> 
> > If you are talking about the bug with 59, then Mattias suggested to
> > exempt the semi-colon from the "display-small-numbers-as-characters"
> > feature.
> 
> Yes - but independent of that I think we want to switch printing using
> `prin1'.

That will probably come with problems of its own...

Stefan, WDYT?

bug#70868: 30.0.50;

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Eli Zaretskii <eliz@gnu.org> writes:

> > Yes - but independent of that I think we want to switch printing using
> > `prin1'.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-emacs-lisp-pp.el-pp-insert-lisp-Always-print-wi.patch --]
[-- Type: text/x-diff, Size: 1294 bytes --]

From 3024833e9557e2400a83f0e71b474c35d927260d Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen@web.de>
Date: Sun, 12 May 2024 19:55:30 +0200
Subject: [PATCH 1/2] * lisp/emacs-lisp/pp.el (pp--insert-lisp): Always print
 with prin1

This fixes an aspect of Bug#70868.
---
 lisp/emacs-lisp/pp.el | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el
index 47805d3dbde..f24b0d55520 100644
--- a/lisp/emacs-lisp/pp.el
+++ b/lisp/emacs-lisp/pp.el
@@ -494,16 +494,12 @@ pp--insert-lisp
             (prin1 sexp (current-buffer)))))
     ;; Print some of the smaller integers as characters, perhaps?
     (integer
-     (if (<= ?0 sexp ?z)
-         (let ((print-integers-as-characters t))
-           (princ sexp (current-buffer)))
-       (princ sexp (current-buffer))))
+     (let ((print-integers-as-characters (<= ?0 sexp ?z)))
+       (prin1 sexp (current-buffer))))
     (string
      (let ((print-escape-newlines t))
        (prin1 sexp (current-buffer))))
-    (symbol
-     (prin1 sexp (current-buffer)))
-    (otherwise (princ sexp (current-buffer)))))
+    (otherwise (prin1 sexp (current-buffer)))))

 (defun pp--format-vector (sexp)
   (insert "[")
--
2.39.2


[-- Attachment #3: Type: text/plain, Size: 39 bytes --]


And while we talk about these lines:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0002-Don-t-try-to-pretty-print-non-lists-as-binding-list.patch --]
[-- Type: text/x-diff, Size: 1057 bytes --]

From d9c32c4bce32838fbe44a0f8bfb4ed04b34d65f7 Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen@web.de>
Date: Sun, 12 May 2024 19:58:14 +0200
Subject: [PATCH 2/2] Don't try to pretty print non-lists as binding list

* lisp/emacs-lisp/pp.el (pp--format-definition): Avoid barfing for SEXPs
like (let X Y) in `pcase' forms: ensure that what we try to print as
a list of bindings actually has an appropriate format.
---
 lisp/emacs-lisp/pp.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el
index f24b0d55520..aae3d2f78bf 100644
--- a/lisp/emacs-lisp/pp.el
+++ b/lisp/emacs-lisp/pp.el
@@ -576,7 +576,8 @@ pp--format-definition
     (unless (consp edebug)
       (setq edebug nil))
     (if (and (consp (car edebug))
-             (eq (caar edebug) '&rest))
+             (eq (caar edebug) '&rest)
+             (proper-list-p (car sexp)))
         (pp--insert-binding (pop sexp))
       (if (null (car sexp))
           (insert "()")
--
2.39.2


[-- Attachment #5: Type: text/plain, Size: 457 bytes --]



> That will probably come with problems of its own...

Unless it's clear: keep in mind that we only speak about atomic objects
here (no sequences) - this helper function is only intended for simple
objects like characters.

Also note that - unless I'm missing some aspect - printing with `princ'
instead of `prin1' will either produce the same result or a broken
result that cannot be `read' - and the function makes the promise to
print code.


Michael.

bug#70868: 30.0.50;

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> > If you are talking about the bug with 59, then Mattias suggested to
>> > exempt the semi-colon from the "display-small-numbers-as-characters"
>> > feature.
>> Yes - but independent of that I think we want to switch printing using
>> `prin1'.
> That will probably come with problems of its own...
> Stefan, WDYT?

`prin1` will have its share of downsides, I guess, but when printing
"arbitrary data", it's definitely a safer choice than `princ` which
is rarely the right thing (except when printing strings, obviously).

This said, I don't see the connection with printing small numbers as
chars.  To print chars using the ELisp syntax you need `prin1-char`:
AFAIK neither `prin1` nor `princ` work (at all).


        Stefan

bug#70868: 30.0.50;

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> `prin1` will have its share of downsides, I guess, but when printing
> "arbitrary data", it's definitely a safer choice than `princ` which
> is rarely the right thing (except when printing strings, obviously).

I hope you only mean strings that contain the printed representation of
an object.  Our `pp--insert-lisp' prints strings in the argument with
`prin1' (of course).


> This said, I don't see the connection with printing small numbers as
> chars.

There is none - but we constantly keep replacing every single `princ'
with `prin1' in that function, one after the other, so I suggest to
switch to `prin1' for all objects and see if anything remains where
that behaves unintuitively.

> To print chars using the ELisp syntax you need `prin1-char`: AFAIK
> neither `prin1` nor `princ` work (at all).

Thanks for that comment - I updated the patch to use `prin1-char':


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Further-tweak-pp-code-printing.patch --]
[-- Type: text/x-diff, Size: 1332 bytes --]

From e041c3a9d295f4c9946bcb693591eb47237cc4fe Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen@web.de>
Date: Sun, 12 May 2024 19:55:30 +0200
Subject: [PATCH] Further tweak pp code printing

This fixes an aspect of Bug#70868.

* lisp/emacs-lisp/pp.el (pp--insert-lisp): Print characters with
`prin1-char'.  In all other cases consistently print with `prin1'.
---
 lisp/emacs-lisp/pp.el | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el
index 47805d3dbde..1ca206cf5db 100644
--- a/lisp/emacs-lisp/pp.el
+++ b/lisp/emacs-lisp/pp.el
@@ -495,15 +495,12 @@ pp--insert-lisp
     ;; Print some of the smaller integers as characters, perhaps?
     (integer
      (if (<= ?0 sexp ?z)
-         (let ((print-integers-as-characters t))
-           (princ sexp (current-buffer)))
-       (princ sexp (current-buffer))))
+         (princ (prin1-char sexp) (current-buffer))
+       (prin1 sexp (current-buffer))))
     (string
      (let ((print-escape-newlines t))
        (prin1 sexp (current-buffer))))
-    (symbol
-     (prin1 sexp (current-buffer)))
-    (otherwise (princ sexp (current-buffer)))))
+    (otherwise (prin1 sexp (current-buffer)))))

 (defun pp--format-vector (sexp)
   (insert "[")
--
2.39.2


[-- Attachment #3: Type: text/plain, Size: 223 bytes --]



And I would leave the specially handled range of integers as is.  Look:
there are really pathological cases that are very ugly.  For example,
?\n competes with 10, a very frequently occurring integer.


Thanks,

Michael.

bug#70868: 30.0.50;

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

> This said, I don't see the connection with printing small numbers as
> chars.  To print chars using the ELisp syntax you need `prin1-char`:
> AFAIK neither `prin1` nor `princ` work (at all).

Did I forget to attach the patch?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Further-tweak-pp-code-printing.patch --]
[-- Type: text/x-diff, Size: 1332 bytes --]

From e041c3a9d295f4c9946bcb693591eb47237cc4fe Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen@web.de>
Date: Sun, 12 May 2024 19:55:30 +0200
Subject: [PATCH] Further tweak pp code printing

This fixes an aspect of Bug#70868.

* lisp/emacs-lisp/pp.el (pp--insert-lisp): Print characters with
`prin1-char'.  In all other cases consistently print with `prin1'.
---
 lisp/emacs-lisp/pp.el | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el
index 47805d3dbde..1ca206cf5db 100644
--- a/lisp/emacs-lisp/pp.el
+++ b/lisp/emacs-lisp/pp.el
@@ -495,15 +495,12 @@ pp--insert-lisp
     ;; Print some of the smaller integers as characters, perhaps?
     (integer
      (if (<= ?0 sexp ?z)
-         (let ((print-integers-as-characters t))
-           (princ sexp (current-buffer)))
-       (princ sexp (current-buffer))))
+         (princ (prin1-char sexp) (current-buffer))
+       (prin1 sexp (current-buffer))))
     (string
      (let ((print-escape-newlines t))
        (prin1 sexp (current-buffer))))
-    (symbol
-     (prin1 sexp (current-buffer)))
-    (otherwise (princ sexp (current-buffer)))))
+    (otherwise (prin1 sexp (current-buffer)))))

 (defun pp--format-vector (sexp)
   (insert "[")
--
2.39.2


[-- Attachment #3: Type: text/plain, Size: 11 bytes --]



Michael.

bug#70868: 30.0.50;

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs@gnu.org> writes:

> Did I forget to attach the patch?

Eh - no, I didn't - please forget my last message.  How embarrassing...

Michael.

bug#70868: 30.0.50;

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> `prin1` will have its share of downsides, I guess, but when printing
>> "arbitrary data", it's definitely a safer choice than `princ` which
>> is rarely the right thing (except when printing strings, obviously).
> I hope you only mean strings that contain the printed representation of
> an object.  Our `pp--insert-lisp' prints strings in the argument with
> `prin1' (of course).

That comment was not specific to `pp--insert-lisp', but much
more general.  As a general rule of thumb `princ` should be called only
with a string as argument (same thing for %s vs %S in `format`).

> Thanks for that comment - I updated the patch to use `prin1-char':

LGTM,


        Stefan

bug#70868: 30.0.50; pp--insert-lisp prints small integers as characters

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Hello again,

I have committed our fix now and close this bug report since we are
done.  Thanks to everybody.


While I was at it I found a branch in the algorithm where we printed an
arbitrary non-list cons using `prin1' for no reason.  Since we have
everything in pp to pretty-print any list and cons, I fixed that:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Don-t-let-pp-fall-back-to-prin1-for-conses.patch --]
[-- Type: text/x-diff, Size: 981 bytes --]

From 804f36d5abdbc38a4664a341aaea563195f79b03 Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen@web.de>
Date: Sun, 26 May 2024 16:31:26 +0200
Subject: [PATCH] Don't let pp fall back to prin1 for conses

* lisp/emacs-lisp/pp.el (pp--insert-lisp): Don't `prin1' non-list
conses; use our pp function for cons and list printing
`pp--format-list' instead.
---
 lisp/emacs-lisp/pp.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el
index 3176ee42533..e550bd4d689 100644
--- a/lisp/emacs-lisp/pp.el
+++ b/lisp/emacs-lisp/pp.el
@@ -491,7 +491,7 @@ pp--insert-lisp
                     (pp--insert-lisp (cadr sexp)))
                 (pp--format-list sexp))))
            (t
-            (prin1 sexp (current-buffer)))))
+            (pp--format-list sexp))))
     ;; Print some of the smaller integers as characters, perhaps?
     (integer
      (if (<= ?0 sexp ?z)
--
2.39.2


[-- Attachment #3: Type: text/plain, Size: 11 bytes --]



Michael.