all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Puzzling behavior from echo area: truncates prompt string at 100 characters?
@ 2011-12-21  1:29 Tom Davey
  2011-12-24  9:31 ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Tom Davey @ 2011-12-21  1:29 UTC (permalink / raw)
  To: help-gnu-emacs

Hello folks,

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?

Thanks,
Tom Davey

-- 
Tom Davey
tom@tomdavey.com
New York NY USA



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Puzzling behavior from echo area: truncates prompt string at 100 characters?
  2011-12-21  1:29 Puzzling behavior from echo area: truncates prompt string at 100 characters? Tom Davey
@ 2011-12-24  9:31 ` Eli Zaretskii
  2011-12-24 10:59   ` Andreas Schwab
  0 siblings, 1 reply; 6+ 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] 6+ messages in thread

* Re: Puzzling behavior from echo area: truncates prompt string at 100 characters?
  2011-12-24  9:31 ` Eli Zaretskii
@ 2011-12-24 10:59   ` Andreas Schwab
  2011-12-24 13:20     ` Eli Zaretskii
  0 siblings, 1 reply; 6+ 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] 6+ 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; 6+ 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] 6+ 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; 6+ 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] 6+ 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; 6+ 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] 6+ messages in thread

end of thread, other threads:[~2011-12-25  6:08 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-21  1:29 Puzzling behavior from echo area: truncates prompt string at 100 characters? Tom Davey
2011-12-24  9:31 ` 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 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.