bug#41814: defmethod cl-print-object is not entirely reliable

bug#41814: defmethod cl-print-object is not entirely reliable

[akater]

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

I'm on Emacs 28.0.50.  I believe cl-print-object method code is not used when it
should be.

emacs -Q

C-x b *scratch* RET

(require 'eieio) C-x C-e RET

(defclass test nil nil) C-x C-e RET

(defmethod cl-print-object ((x test) s) (princ "#<test>" s)) C-x C-e RET

(make-feature 'test) RET C-u C-x C-e

For me, this prints like a structure (?): #s(test)

Now,

C-x 3

M-x ielm RET

(make-feature 'test) RET

This does make use of cl-print-object method:

#<test>

Structure method seems to also be used in org-babel evaluations.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

bug#41814: defmethod cl-print-object is not entirely reliable

[Michael Heerdegen]

akater <nuclearspace@gmail.com> writes:

> I'm on Emacs 28.0.50.  I believe cl-print-object method code is not
> used when it should be.

> (make-feature 'test) RET C-u C-x C-e
>
> For me, this prints like a structure (?): #s(test)

Yes, this doesn't use cl-print at all.  And I think that makes sense:
when inserting a value into a buffer, readability is important (that
doesn't make a difference in your case, though).

We have different printers now in Elisp, and implementing
cl-print-object only has an effect when cl-print is used.

I dunno if that fact could be better documented to avoid this kind of
confusion.

Michael.

bug#41814: defmethod cl-print-object is not entirely reliable

[akater]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Yes, this doesn't use cl-print at all.  And I think that makes sense:
> when inserting a value into a buffer, readability is important (that
> doesn't make a difference in your case, though).

I'm afraid I disagree.  Why would anyone write a printing method if they
didn't aim for better readability in the first place?

My example was an MWE.  This behaviour concerns me because I have
classes with plenty of slots, and I actually often return /a tree/ of
corrsponding objects.  It certainly looks less readable when cl-print is
not used.  The whole point of defining a printing method is to have
fine-tuned printed represntations.  If it's not actually used
[everywhere, of course] I just don't understand why it's there at all.

IELM, too, “inserts value into a buffer” so I don't really get this
distinction either.

I'd have my personal itch scratched if I could at least specify cl-print
use in Org blocks but this doesn't feel right at all.

Does Emacs have object inspector?  If not, I'd guess its lack is the
real reason behind the desire to keep overly detailed output in some
places.

bug#41814: defmethod cl-print-object is not entirely reliable

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Yes, this doesn't use cl-print at all.  And I think that makes sense:
> when inserting a value into a buffer, readability is important (that
> doesn't make a difference in your case, though).
>
> We have different printers now in Elisp, and implementing
> cl-print-object only has an effect when cl-print is used.

Yup -- I don't think there's a bug here.  The standard Emacs
eval/printing commands aren't affected by the cl print definitions, but
instead uses a slew of different things to DWIM the printing, and we
can't change that.

> I dunno if that fact could be better documented to avoid this kind of
> confusion.

I don't think anything in our documentation (as far as I know) should
lead anybody to think that doing something in cl-print should affect
`C-u C-x C-e', so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no