GNU bug report logs - #55853
28.1; Please document f#(...) syntax in Elisp manual

Previous Next

Full log

Message #19 received at 55853 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: "55853 <at> debbugs.gnu.org" <55853 <at> debbugs.gnu.org>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: RE: [External] : Re: bug#55853: 28.1; Please document f#(...) syntax
 in Elisp manual
Date: Tue, 5 Jul 2022 15:23:06 +0000

> > But is there any chance this "pretty"-printing itself
> > can be made more human-friendly / communicative?
> >
> > Aside from (I guess) naming the formal parameters, it
> > looks like it just says "BLAT$%@#(*&{}:"|?><(/.,!!".
> 
> Well, that's what byte code looks like.  Apart from that, "it" is a
> clickable button that will disassemble that code for you if you click
> it.  Not good enough?

Dunno whether it's good enough.  Depends on why someone
might want to understand what's printed.

From the original thread:

  this is apparently "special read syntax", i.e., Lisp
  reader syntax that's not readable by the Lisp reader
  but is meant to communicate something to humans. ...

  What the source code for the function is; what the
  function does (e.g., it's doc); or where it's defined
  -- nothing like that is conveyed in the "pretty"-print.
  And whether "compiled" there means byte-compiled or
  "native"-compiled also isn't made clear.

(Dunno whether any of those missing things has now been
added as part of the bug fix.)

Maybe instead of (or in addition to) a disassembly, a
user could be pointed - a least in some cases - to the
original source code (Lisp or C)?

Previous Next

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