GNU bug report logs - #38736
26.3; ellipsis in `*Messages*', doc of `format' etc.

Previous Next

Full log

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: 38736-done <at> debbugs.gnu.org
Subject: RE: bug#38736: 26.3; ellipsis in `*Messages*', doc of `format' etc.
Date: Wed, 25 Dec 2019 12:54:54 -0800 (PST)

> > > How did you get the ellipsis in *Messages*?
> >
> > By a call (message "Result: %S" result), where
> > the value of `result' is a long list.
> 
> That's not a "call", that's evaluation.

Huh?  It's in code, in a function body.  But of
course, code (source/byte-compiled) is evaluated
(interpreted, executed, whatever term you prefer).

Executing that code means evaluating that sexp,
yes.  And?  It's not clear what hairs you are
trying to split, here.

> And using %S is a prerequisite, AFAIK; you won't
> get the ellipsis with other formats.

Correct, which is why I said (message "%S"), and
not just calling `message'.

> Like I said: eval's doc string documents this
> feature,

I see nothing in the doc string of `eval' that
tells you `%S' in the `message' format string is
controlled by `print-length'.  Or even anything
close to it.

 eval is a built-in function in 'C source code'.
 (eval FORM &optional LEXICAL)
 Evaluate FORM and return its value.

 If LEXICAL is t, evaluate using lexical scoping.
 LEXICAL can also be an actual lexical environment,
 in the form of an alist mapping symbols to their value.

Pointing to `eval' here seems like a very red
herring.

> you just looked for the documentation in the
> wrong place

`C-h f eval' is the right place?  How so?  How
does it help?

> (and still found it, albeit through a long path).

Exactly what I reported.  A long road to get to
info about a commonly used construct.

(Or do you still maintain that %S is rarely used
with `message'?)

And note that if you try to find it in the Elisp
manual, starting with `message' (node `Displaying
Messages') and linking to node `Formatting Strings',
then what you find for %S is this:

 '%S'
 Replace the specification with the printed representation of the
 object, made with quoting (that is, using 'prin1'-*note Output
 Functions::).  Thus, strings are enclosed in '"' characters, and
 '\' characters appear where necessary before special characters.

Then you need to follow the `Output Functions'
link to read about `prin1'.  Again, several links
to follow.

Even in `Formatting Strings' it would make sense
to not give the impression that `prin1' is only
about "quoting".

  "quoting (that is, using `prin1'"

`prin1's use of variables `print-length' etc.
have nothing to do with "quoting".

> So I see nothing to be done here, and I'm
> closing this bug report.

Too bad, once again.

Previous Next

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