all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: 38736-done@debbugs.gnu.org
Subject: bug#38736: 26.3; ellipsis in `*Messages*', doc of `format' etc.
Date: Wed, 25 Dec 2019 12:54:54 -0800 (PST)	[thread overview]
Message-ID: <4a9b955a-ac97-41d9-a373-fc37b37581a4@default> (raw)
In-Reply-To: <<83d0ccuxoe.fsf@gnu.org>>

> > > 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.





       reply	other threads:[~2019-12-25 20:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<<006e6244-dd0a-46a8-8c61-36744b3216de@default>
     [not found] ` <<<83pngcv5ha.fsf@gnu.org>
     [not found]   ` <<32378b4e-d158-48d5-a48c-7afde59f5d32@default>
     [not found]     ` <<83d0ccuxoe.fsf@gnu.org>
2019-12-25 20:54       ` Drew Adams [this message]
2019-12-26  3:28         ` bug#38736: 26.3; ellipsis in `*Messages*', doc of `format' etc Eli Zaretskii
     [not found] <<<<006e6244-dd0a-46a8-8c61-36744b3216de@default>
     [not found] ` <<<<83pngcv5ha.fsf@gnu.org>
     [not found]   ` <<<32378b4e-d158-48d5-a48c-7afde59f5d32@default>
     [not found]     ` <<<83d0ccuxoe.fsf@gnu.org>
     [not found]       ` <<4a9b955a-ac97-41d9-a373-fc37b37581a4@default>
     [not found]         ` <<838smzvk86.fsf@gnu.org>
2019-12-26 17:49           ` Drew Adams
     [not found] <<006e6244-dd0a-46a8-8c61-36744b3216de@default>
     [not found] ` <<83pngcv5ha.fsf@gnu.org>
2019-12-25 16:44   ` Drew Adams
2019-12-25 17:23     ` Eli Zaretskii
2019-12-26  3:24       ` Michael Heerdegen
2019-12-26 16:23         ` Eli Zaretskii
2019-12-24 21:02 Drew Adams
2019-12-25 14:34 ` Eli Zaretskii

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

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

  git send-email \
    --in-reply-to=4a9b955a-ac97-41d9-a373-fc37b37581a4@default \
    --to=drew.adams@oracle.com \
    --cc=38736-done@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.