bug#64835: ‘describe-variable’ unconditionally let-binds ‘print-circle’ to t

bug#64835: ‘describe-variable’ unconditionally let-binds ‘print-circle’ to t

[Sebastian Miele]

That was not the case in Emacs 28.  It seems to have been introduced
in the following commit:

  2c18969c810f338d73beda592ee5af7103132e97
  Author:     Stefan Monnier <monnier@iro.umontreal.ca>
  AuthorDate: Thu Mar 2 02:08:08 2017 -0500
  Commit:     Stefan Monnier <monnier@iro.umontreal.ca>
  CommitDate: Thu Mar 2 02:08:32 2017 -0500

  * lisp/help-fns.el (describe-variable): Use cl-print for the value

  Use `pp-buffer' rather than `pp' so as to avoid calling prin1 twice.

2017 is a while ago.  The first pretest release of Emacs 28 was in
December 2021.  So the commit must have entered the current emacs-29
branch in some "non-linear" way.

The problem is that the effect of ‘print-circle’ being t pertains to
all sharing, not just sharing that leads to circles.  And that has the
effect, that the output can become arbitrarily unreadable.  Consider
for example:

  (require 'ispell)
  (ispell-set-spellchecker-params)
  (describe-variable 'ispell-dictionary-alist)

The display of the value in my machine contains, e.g., "(nil #1# #2# #3#
t #4# nil utf-8)".

I do not see the reason for hard-coding ‘print-circle’ to t in
‘describe-variable’.  The only reason I can imagine would be the
prevention of infinite loops.  But that cannot be the case, because
even with ‘print-circle’ nil, the printing routines seem to check for
circularity and handle it gracefully in the output.

Is this a bug or a necessity that I do not understand, yet?

The NEWS file does not mention this change.

In general (and somewhat unrelated), it would be nice if ‘print-circle’
would be split into two things: (1) make explicit all sharing (as is
done now), and (2) make explicit only a subset of sharing that resolves
all circles.  (The latter would in at least two aspects still be
different from the graceful handling mentioned above when ‘print-circle’
is nil.)

-----

In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
 cairo version 1.17.8) of 2023-07-23 built on huette
Repository revision: 906ecf442c43da98e6b8c7488f549691901690e9
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Arch Linux

Configured using:
 'configure --with-x-toolkit=gtk --with-native-compilation=yes
 --with-tree-sitter --with-json --with-mailutils --with-imagemagick'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2
XPM GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: C.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils pp shortdoc text-property-search
mouse-copy mouse-drag thingatpt time-date cl-print byte-opt help-fns
radix-tree ispell comp comp-cstr warnings icons subr-x rx cl-seq cl-macs
gv cl-extra help-mode cl-loaddefs cl-lib bytecomp byte-compile rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 102484 8121)
 (symbols 48 7638 0)
 (strings 32 28748 4608)
 (string-bytes 1 869676)
 (vectors 16 19807)
 (vector-slots 8 344131 11905)
 (floats 8 148 62)
 (intervals 56 1312 1)
 (buffers 984 14))

bug#64835: ‘describe-variable’ unconditionally let-binds ‘print-circle’ to t

[Eli Zaretskii]

> From: Sebastian Miele <iota@whxvd.name>
> Date: Mon, 24 Jul 2023 18:42:09 +0200
> 
> That was not the case in Emacs 28.  It seems to have been introduced
> in the following commit:
> 
>   2c18969c810f338d73beda592ee5af7103132e97
>   Author:     Stefan Monnier <monnier@iro.umontreal.ca>
>   AuthorDate: Thu Mar 2 02:08:08 2017 -0500
>   Commit:     Stefan Monnier <monnier@iro.umontreal.ca>
>   CommitDate: Thu Mar 2 02:08:32 2017 -0500
> 
>   * lisp/help-fns.el (describe-variable): Use cl-print for the value
> 
>   Use `pp-buffer' rather than `pp' so as to avoid calling prin1 twice.
> 
> 2017 is a while ago.  The first pretest release of Emacs 28 was in
> December 2021.  So the commit must have entered the current emacs-29
> branch in some "non-linear" way.

I don't think so.  I see this code in Emacs 28.1.  So I'm not sure why
you didn't see this behavior in Emacs 28, if indeed it is caused by
print-circle.

> The problem is that the effect of ‘print-circle’ being t pertains to
> all sharing, not just sharing that leads to circles.  And that has the
> effect, that the output can become arbitrarily unreadable.  Consider
> for example:
> 
>   (require 'ispell)
>   (ispell-set-spellchecker-params)
>   (describe-variable 'ispell-dictionary-alist)
> 
> The display of the value in my machine contains, e.g., "(nil #1# #2# #3#
> t #4# nil utf-8)".
> 
> I do not see the reason for hard-coding ‘print-circle’ to t in
> ‘describe-variable’.  The only reason I can imagine would be the
> prevention of infinite loops.  But that cannot be the case, because
> even with ‘print-circle’ nil, the printing routines seem to check for
> circularity and handle it gracefully in the output.
> 
> Is this a bug or a necessity that I do not understand, yet?
> 
> The NEWS file does not mention this change.
> 
> In general (and somewhat unrelated), it would be nice if ‘print-circle’
> would be split into two things: (1) make explicit all sharing (as is
> done now), and (2) make explicit only a subset of sharing that resolves
> all circles.  (The latter would in at least two aspects still be
> different from the graceful handling mentioned above when ‘print-circle’
> is nil.)

Adding Stefan to the discussion.

bug#64835: ‘describe-variable’ unconditionally let-binds ‘print-circle’ to t

[Sebastian Miele]

> From: Eli Zaretskii <eliz@gnu.org>
> Date: Mon, 2023-07-24 20:03 +0300
>
>> From: Sebastian Miele <iota@whxvd.name>
>> Date: Mon, 24 Jul 2023 18:42:09 +0200
>>
>> That was not the case in Emacs 28.  It seems to have been introduced
>> in the following commit:
>>
>>   2c18969c810f338d73beda592ee5af7103132e97
>>   Author:     Stefan Monnier <monnier@iro.umontreal.ca>
>>   AuthorDate: Thu Mar 2 02:08:08 2017 -0500
>>   Commit:     Stefan Monnier <monnier@iro.umontreal.ca>
>>   CommitDate: Thu Mar 2 02:08:32 2017 -0500
>>
>>   * lisp/help-fns.el (describe-variable): Use cl-print for the value
>>
>>   Use `pp-buffer' rather than `pp' so as to avoid calling prin1 twice.
>>
>> 2017 is a while ago.  The first pretest release of Emacs 28 was in
>> December 2021.  So the commit must have entered the current emacs-29
>> branch in some "non-linear" way.
>
> I don't think so.  I see this code in Emacs 28.1.  So I'm not sure why
> you didn't see this behavior in Emacs 28, if indeed it is caused by
> print-circle.

I must have made a mistake when I tested with Emacs 28 yesterday.  After
checking again, the behavior clearly is in Emacs 28, too.

bug#64835: ‘describe-variable’ unconditionally let-binds ‘print-circle’ to t

[Michael Heerdegen]

Sebastian Miele <iota@whxvd.name> writes:

>   2c18969c810f338d73beda592ee5af7103132e97
>   Author:     Stefan Monnier <monnier@iro.umontreal.ca>
>   AuthorDate: Thu Mar 2 02:08:08 2017 -0500
>
>   * lisp/help-fns.el (describe-variable): Use cl-print for the value
>   [...]
>

>   (describe-variable 'ispell-dictionary-alist)
>
> The display of the value in my machine contains, e.g., "(nil #1# #2# #3#
> t #4# nil utf-8)".
> [...]
> I do not see the reason for hard-coding ‘print-circle’ to t in
> ‘describe-variable’.

I think I agree.  Both values might be the optimum in different cases.
But most users are probably never interested in shared structures, some
will even be confused.  And those that are interested also know how to
print using print-circle enabled themselves.

Stefan, would it be ok to turn off `print-circle' for
`describe-variable' again, or would this break something in the new
code?


TIA,

Michael.

bug#64835: ‘describe-variable’ unconditionally let-binds ‘print-circle’ to t

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

> Stefan, would it be ok to turn off `print-circle' for
> `describe-variable' again, or would this break something in the new
> code?

I can't think of any reason it would break anything (famous last
words, of course :-)


        Stefan

bug#64835: ‘describe-variable’ unconditionally let-binds ‘print-circle’ to t

[Michael Heerdegen]

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

> > Stefan, would it be ok to turn off `print-circle' for
> > `describe-variable' again, or would this break something in the new
> > code?
>
> I can't think of any reason it would break anything (famous last
> words, of course :-)

I have a strange feeling.  There was not some problem with numbering in
the #N syntax (with `print-circle' off) that lead you to this change, or
something like this?  I vaguely remember there was something...

Michael.

bug#64835: ‘describe-variable’ unconditionally let-binds ‘print-circle’ to t

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

>> > Stefan, would it be ok to turn off `print-circle' for
>> > `describe-variable' again, or would this break something in the new
>> > code?
>> I can't think of any reason it would break anything (famous last
>> words, of course :-)
> I have a strange feeling.  There was not some problem with numbering in
> the #N syntax (with `print-circle' off) that lead you to this change, or
> something like this?  I vaguely remember there was something...

There was recently an inconsistency in the numbering, but that wasn't
a serious problem, it's been fixed, and it was not related to use of
`print-circle` (IIRC I activated `print-circle` there because of
a case where I bumped into where it was "obvious" that `print-circle`
would make it a lot more readable and I didn't realize it could make it
harder to read other values for the unsuspecting user).


        Stefan

bug#64835: ‘describe-variable’ unconditionally let-binds ‘print-circle’ to t

[Mattias Engdegård]

Any way we can toggle print-circle interactively in the display? Perhaps along with depth or length limits.

It would be neat if print-circle would default to t only for actually circular values, as opposed to mere DAGs.

bug#64835: ‘describe-variable’ unconditionally let-binds ‘print-circle’ to t

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

> Any way we can toggle print-circle interactively in the display? Perhaps
> along with depth or length limits.

I think it would be fairly easy to print with `print-circle` by default
and allow users to click on the confusing #N= or #N# to switch to
a display without `print-circle`, but I'm not sure it would help the
confused users very much.

And doing the opposite (i.e. starting from the non-print-circle output)
seems a lot less obvious/natural :-(


        Stefan

bug#64835: ‘describe-variable’ unconditionally let-binds ‘print-circle’ to t

[Mattias Engdegård]

15 aug. 2023 kl. 04.55 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

> And doing the opposite (i.e. starting from the non-print-circle output)
> seems a lot less obvious/natural :-(

Yes, well, we are probably in a minority wanting the technically precise information up-front, and even then it's true that in most cases any non-circular structure sharing is irrelevant.