help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is the type of user input?


From: Kevin Rodgers
Subject: Re: What is the type of user input?
Date: Thu, 28 Oct 2004 10:40:24 -0600
User-agent: Mozilla Thunderbird 0.8 (X11/20040916)

Hattuari wrote:
> Kevin Rodgers wrote:
>>gl-type is a string.  Since the paste-gl-type-map property list is keyed
>>by symbols, plist-get returns nil.
>
> That's what I was missing.  I was assuming that 'symbol-name implicitly
> meant symbol would evaluate to a string.  Now that I've read the first
> several chapters of the Elisp Reference Manual, I have a better idea of
> what's going on.

'foo is equivalent to (quote foo), which is the symbol whose name is
"foo".

The symbol-name name function takes a symbol and returns its name
string, and the intern function takes a string and returns the symbol
with that name.

>>The %s message specifier can be
>>applied to any Lisp object, and symbols and strings are formatted the
>>same.
>>
>>The solution is to either (1) read gl-type with the %S code or (2) call
>>plist-get with (intern gl-type).
>
> I opted for trying an association array, which also worked.

I assume you mean association list.  But whether you have a (KEY-1
VALUE-1 ... KEY-N VALUE-N) property list where they keys are by
definition symbols or a ((KEY-1 . VALUE-1) ... (KEY-N . VALUE-N)) alist
where the keys can be arbitrary lisp objects, you still have to make
sure that you pass a key of the correct type to plist-get or assoc,
respectively.

> I will try your suggestion of using (intern gl-type).  As for reading
> gl-type with %S, I'm not sure what that would do for me.  The only use
> I know for that is to use it in a string format.

Oops, I meant S.  (You used s in the interactive spec to read gl-type as
a string; using S would bind gl-type to the intern'ed symbol.)

>> > OTOH, when I evaluate this expression in an emacs-lisp buffer
>> > (paste-gl-array 'GLbyte 4 'v), I see the following in the echo area:
>> >
>> > gl-type=GLbyte, gl-components=4, gl-vector=v , suffix=b
>> >
>> > That is the desired result.  Why is this not the result of calling the
>> > function as an interactive command as described above?
>> >
>> > I will continue to look for an answer in the documentation, but any
>> > help from someone who knows the answer would be appreciated.
>>
>>It's not that hard to find:
>>
>>`C-h f message' has a link to the doc string for `format', which has a
>>link to the doc string for `princ' in its description of %s:
>>
>>,----[ C-h f princ RET ]
>>| princ is a built-in function.
>>| (princ OBJECT &optional PRINTCHARFUN)
>>|
>>| Output the printed representation of OBJECT, any Lisp object.
>>| No quoting characters are used; no delimiters are printed around
>>| the contents of strings.
>>|
>>| OBJECT is any of the Lisp data types: a number, a string, a symbol,
>>| a list, a buffer, a window, a frame, etc.
>>|
>>| A printed representation of an object is text which describes that
>>| object.
>>...`----
>
>
> That doesn't tell me anything that I see as addressing my problem. Can you
> explain how that answers my question as to why the two symbols were not
> comparing as I had expected?

You assumed that since the symbol and the string looked the same when
displayed in the echo area by (message "%s" ...), that they were
actually the same.  The message -> format -> princ doc strings explain
that a symbol and its name string will be displayed the same by (message
"%s"), even though they are different objects of different types.

>  (type-of gl-type) was what showed me what I was doing wrong.  I tried to
> post back to the newsgroup, but my ISP was down.

--
Kevin Rodgers


reply via email to

[Prev in Thread] Current Thread [Next in Thread]