From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kevin Rodgers Newsgroups: gmane.emacs.help Subject: Re: What is the type of user input? Date: Thu, 28 Oct 2004 10:40:24 -0600 Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <2uclntF28kv0vU1@uni-berlin.de> References: <2uaf6cF28g520U1@uni-berlin.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1098981739 2867 80.91.229.6 (28 Oct 2004 16:42:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 28 Oct 2004 16:42:19 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Oct 28 18:42:14 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CNDLn-00024f-00 for ; Thu, 28 Oct 2004 18:42:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNDTb-0000mh-1N for geh-help-gnu-emacs@m.gmane.org; Thu, 28 Oct 2004 12:50:15 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!newsmi-us.news.garr.it!newsmi-eu.news.garr.it!NewsITBone-GARR!fu-berlin.de!uni-berlin.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 88 Original-X-Trace: news.uni-berlin.de HXgQg4c/k4kHK5naH1JrTgfAH5wzWdVvNATlDM+qQMDoaJB/c= User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en In-Reply-To: Original-Xref: shelby.stanford.edu gnu.emacs.help:126168 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:21548 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:21548 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