[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