* Re: Puzzling behavior from echo area: truncates prompt string at 100 characters?
[not found] <CAG1pqKyXYbLMhZqk_Z_j8x6SZYv_3iZ2Fi5D2s6Ah+7eXwA6=g@mail.gmail.com>
@ 2011-12-24 9:31 ` Eli Zaretskii
2011-12-24 10:59 ` Andreas Schwab
0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2011-12-24 9:31 UTC (permalink / raw)
To: Tom Davey; +Cc: emacs-devel
[Moved here from help-gnu-emacs.]
> Date: Tue, 20 Dec 2011 20:29:57 -0500
> From: Tom Davey <tdavey@gmail.com>
>
> I'm using Emacs 24.0.50.1. The following "message" command, with an
> arbitrarily chosen argument string of exactly 150 characters --
>
> (message "0123456789 123456789 223456789 323456789 423456789 523456789
> 623456789 723456789 823456789 923456789 023456789 123456789 223456789
> 323456789 423456789")
>
> -- displays the entire length of the string (all 150 characters) in
> the minibuffer's echo area, as one would expect. In fact, I find that
> the echo area frame will expand in height to display even much longer
> messages. (The variable "message-truncate-lines" is nil.)
>
> However, if the same 150-character string becomes an argument to an
> "(interactive)" declaration in a defun() function, like this --
>
> (interactive "c0123456789 123456789 223456789 323456789 423456789
> 523456789 623456789 723456789 823456789 923456789 023456789 123456789
> 223456789 323456789 423456789")
>
> -- then the display of the prompt string in the echo area is
> truncated. Only the first 99 characters display; the remainder of the
> echo area (to the right) is unused and empty. Nor does the echo area's
> frame expand in height, as it does with the "message" function.
>
> Naturally, in a real-world application my prompt string would not be
> composed of integers but of helpful alphanumeric text. However, no
> matter what form of a prompt string I supply to the "interactive"
> declaration, the echo area truncates it at the 100th character.
>
> Does anybody have an idea how I might get a long prompt in an
> interactive declaration to fully display in the echo area?
This happens because call-interactively arbitrarily truncates the
prompt at the 99th character:
char prompt1[100];
...
strncpy (prompt1, tem + 1, sizeof prompt1 - 1);
prompt1[sizeof prompt1 - 1] = 0;
tem1 = strchr (prompt1, '\n');
if (tem1) *tem1 = 0;
visargs[0] = build_string (prompt1);
if (strchr (prompt1, '%'))
callint_message = Fformat (i, visargs);
else
callint_message = visargs[0];
...
case 'c': /* Character */
/* Prompt in `minibuffer-prompt' face. */
Fput_text_property (make_number (0),
make_number (SCHARS (callint_message)),
Qface, Qminibuffer_prompt, callint_message);
args[i] = Fread_char (callint_message, Qnil, Qnil);
This limitation was there since 1991, but AFAICS it is not documented
anywhere.
Do we want to keep this limitation? If so, it should be at least
documented.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Puzzling behavior from echo area: truncates prompt string at 100 characters?
2011-12-24 9:31 ` Puzzling behavior from echo area: truncates prompt string at 100 characters? Eli Zaretskii
@ 2011-12-24 10:59 ` Andreas Schwab
2011-12-24 13:20 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Andreas Schwab @ 2011-12-24 10:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Tom Davey, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> This limitation was there since 1991, but AFAICS it is not documented
> anywhere.
I don't think this was a deliberate decision, just sloppy coding.
> Do we want to keep this limitation? If so, it should be at least
> documented.
I can trivially be lifted:
diff --git a/src/callint.c b/src/callint.c
index 80e24f6..8dcf9a6 100644
--- a/src/callint.c
+++ b/src/callint.c
@@ -274,7 +274,6 @@ invoke it. If KEYS is omitted or nil, the return value of
ptrdiff_t i, nargs;
int foo;
- char prompt1[100];
char *tem1;
int arg_from_tty = 0;
struct gcpro gcpro1, gcpro2, gcpro3, gcpro4, gcpro5;
@@ -491,13 +490,8 @@ invoke it. If KEYS is omitted or nil, the return value of
tem = string;
for (i = 1; *tem; i++)
{
- strncpy (prompt1, tem + 1, sizeof prompt1 - 1);
- prompt1[sizeof prompt1 - 1] = 0;
- tem1 = strchr (prompt1, '\n');
- if (tem1) *tem1 = 0;
-
- visargs[0] = build_string (prompt1);
- if (strchr (prompt1, '%'))
+ visargs[0] = make_string (tem + 1, strcspn (tem + 1, "\n"));
+ if (strchr (SSDATA (visargs[0]), '%'))
callint_message = Fformat (i, visargs);
else
callint_message = visargs[0];
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: Puzzling behavior from echo area: truncates prompt string at 100 characters?
2011-12-24 10:59 ` Andreas Schwab
@ 2011-12-24 13:20 ` Eli Zaretskii
2011-12-24 17:41 ` Tom Davey
2011-12-25 6:08 ` Chong Yidong
0 siblings, 2 replies; 5+ messages in thread
From: Eli Zaretskii @ 2011-12-24 13:20 UTC (permalink / raw)
To: Andreas Schwab; +Cc: tdavey, emacs-devel
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Tom Davey <tdavey@gmail.com>, emacs-devel@gnu.org
> Date: Sat, 24 Dec 2011 11:59:36 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > This limitation was there since 1991, but AFAICS it is not documented
> > anywhere.
>
> I don't think this was a deliberate decision, just sloppy coding.
Most probably.
> > Do we want to keep this limitation? If so, it should be at least
> > documented.
>
> I can trivially be lifted:
Assuming Stefan and Chong approve, I think you should install this.
Thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Puzzling behavior from echo area: truncates prompt string at 100 characters?
2011-12-24 13:20 ` Eli Zaretskii
@ 2011-12-24 17:41 ` Tom Davey
2011-12-25 6:08 ` Chong Yidong
1 sibling, 0 replies; 5+ messages in thread
From: Tom Davey @ 2011-12-24 17:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andreas Schwab, emacs-devel
Eli Zaretskii writes to Andreas Schwab:
> Assuming Stefan and Chong approve, I think you should install this.
I am not a programmer, just an IT business guy. That my little
question might result in a useful patch to Emacs is beyond gratifying.
Thanks for making my day.
Tom Davey
--
Tom Davey
tom@tomdavey.com
New York NY USA
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Puzzling behavior from echo area: truncates prompt string at 100 characters?
2011-12-24 13:20 ` Eli Zaretskii
2011-12-24 17:41 ` Tom Davey
@ 2011-12-25 6:08 ` Chong Yidong
1 sibling, 0 replies; 5+ messages in thread
From: Chong Yidong @ 2011-12-25 6:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: tdavey, Andreas Schwab, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> > Do we want to keep this limitation? If so, it should be at least
>> > documented.
>>
>> I can trivially be lifted:
>
> Assuming Stefan and Chong approve, I think you should install this.
Absolutely: please to commit, and thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-12-25 6:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAG1pqKyXYbLMhZqk_Z_j8x6SZYv_3iZ2Fi5D2s6Ah+7eXwA6=g@mail.gmail.com>
2011-12-24 9:31 ` Puzzling behavior from echo area: truncates prompt string at 100 characters? Eli Zaretskii
2011-12-24 10:59 ` Andreas Schwab
2011-12-24 13:20 ` Eli Zaretskii
2011-12-24 17:41 ` Tom Davey
2011-12-25 6:08 ` Chong Yidong
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).