Re: keeping the arglist

[lynch@aristotle.ils.nwu.edu]

>> 
>>     Date: Fri, 20 Mar 1992 20:00 PST
>>     From: cfry@mit.edu (Christopher Fry)
>> 
>>     > a Fred command analogous c-Sh-A on the lispm
>>     >should be easy to implement.
>> 
>>     Yes! I've been thinking the same thing. To make the user feel confident that the
>>     machine is giving him the arglist to foo instead of bar, the minibuffer printout
>>     should include the name of the fn too.It could just print a fn call of the fn
>>     with the argnames in place of the args. Example:
>>     (foo argname1 argname2 &optional argname3)
>> 
>> This is OK for FOO, but doesn't work as well for
>> DEFINE-PRESENTATION-TO-COMMAND-TRANSLATOR (a legitimate symbol in
>> the CLIM package), unless we all get much wider screens.
>I sent off some ideas about this, but perhaps they didn't get to everybody on the
>list. One was simply have an environment variable whose value is the maximum number
>of chars of the fn name to display when you ask for the arglist.
>You could set it to 0 or 4 or 10. Even if you can't get the full name,
>you should be able to get enough of it in the context that your in
>to make you feel secure that its refering to the right fn.

Actually, I've always thought that the horizontal scroll bar at the bottom
of a Fred window should scroll the mini-buffer as well as the regular
Fred-buffer.

I was quite disappointed when this didn't happen the first time I got an
arglist *way* too long to fit in the mini-buffer.

This solution is, IMHO, "better" than truncating the function name because:
A.  It's often bad to truncate function names, esp. when using structs et
al.
B.  Many builtin functions with short names have lotsa keyword args

While this solution may not be intuitively *obvious* to everyone, it does
make sense.  It *may* be easier to implement at this late date.  Yeah,
right.  :-)

It also may open up more uses of a mini-buffer in specially defined
windows...It simplifies the use of a mini-buffer if one can be reassured
that *all* the text is accessible to the user all the time.

Sorry I didn't post this idea earlier.  I had quite forgotten it until I
saw this post.  Don't know what triggered it...
"TANSTAAFL" Rich lynch@ils.nwu.edu