GNU bug report logs -
#38736
26.3; ellipsis in `*Messages*', doc of `format' etc.
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Tue, 24 Dec 2019 21:04:01 UTC
Severity: minor
Found in version 26.3
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Wed, 25 Dec 2019 19:23:13 +0200
with message-id <83d0ccuxoe.fsf <at> gnu.org>
and subject line Re: bug#38736: 26.3; ellipsis in `*Messages*', doc of `format' etc.
has caused the debbugs.gnu.org bug report #38736,
regarding 26.3; ellipsis in `*Messages*', doc of `format' etc.
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
38736: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38736
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
The doc string of `format' doesn't tell you anything about control by
`print-level', `print-length', etc. Please consider adding such info.
Consider trying to figure out, when looking at a message in
`*Messages*', why a long list value shows ellipsis ("..."), instead of
showing all the elements. You try `C-h f message', which says nothing
about this. The most it does is provide a bunch of details about the
formatting intermediary `format-message', imposed since Emacs 25.
Are details about %, `, and ' so important for `message' that they
merit a paragraph, but `print-level' and `print-length' are not so
important?
(What's more: the doc string for `message' goes into more detail than
the one for `format-message', which doesn't even mention %, even
though the former tells you to refer to the latter "for details".)
Following the `format-message' link, you still get no clue about this,
but you then follow a link for `format'. There you still get no clue
about it, but you see that %S uses `prin1'.
Following the `prin1' link you finally find out that you can control
`message's use of ellipsis using `print-length' and `print-level'.
Users shouldn't have to go through all of that (and that even assumes
that they are able to guess that following just that thread might get
them somewhere useful).
What's true for `message' is also true for `error', etc. At least the
doc of `format' - and probably its often-used callers, such as `message'
- should specifically mention these "print"-controlling (really just
formatting) variables.
In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
of 2019-08-29
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor `Microsoft Corp.', version 10.0.17763
Configured using:
`configure --without-dbus --host=x86_64-w64-mingw32
--without-compress-install 'CFLAGS=-O2 -static -g3''
[Message part 3 (message/rfc822, inline)]
> Date: Wed, 25 Dec 2019 08:44:53 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 38736 <at> debbugs.gnu.org
>
> > > Consider trying to figure out, when looking at a message in
> > > `*Messages*', why a long list value shows ellipsis ("..."),
> > > instead of showing all the elements.
> >
> > 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. And using %S is a
prerequisite, AFAIK; you won't get the ellipsis with other formats.
Like I said: eval's doc string documents this feature, you just looked
for the documentation in the wrong place (and still found it, albeit
through a long path). So I see nothing to be done here, and I'm
closing this bug report.
This bug report was last modified 5 years and 208 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.