unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: akater <nuclearspace@gmail.com>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: 41814@debbugs.gnu.org
Subject: bug#41814: defmethod cl-print-object is not entirely reliable
Date: Mon, 06 Jul 2020 19:01:12 +0000	[thread overview]
Message-ID: <873664wjrb.fsf@gmail.com> (raw)
In-Reply-To: <878sgs4m2b.fsf@web.de>

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.





  reply	other threads:[~2020-07-06 19:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-11 20:05 bug#41814: defmethod cl-print-object is not entirely reliable akater
2020-06-12 10:26 ` Michael Heerdegen
2020-07-06 19:01   ` akater [this message]
2021-06-13 11:23   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=873664wjrb.fsf@gmail.com \
    --to=nuclearspace@gmail.com \
    --cc=41814@debbugs.gnu.org \
    --cc=michael_heerdegen@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).