home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / gnu / emacs / help / 5263 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  1.5 KB
  1. Path: sparky!uunet!dove!dove.nist.gov!klm
  2. From: klm@cam.nist.gov (Ken Manheimer)
  3. Newsgroups: gnu.emacs.help
  4. Subject: Re: Why does completing-read take an ALIST?
  5. Message-ID: <KLM.93Jan5231551@coil.cam.nist.gov>
  6. Date: 6 Jan 93 04:15:51 GMT
  7. References: <1993Jan6.001155.1238@spock.retix.com>
  8. Sender: news@dove.nist.gov
  9. Distribution: na
  10. Organization: Nat'l Institute of Standards and Technology
  11. Lines: 26
  12. In-reply-to: dspencer@mproj.retix.com's message of 6 Jan 93 00:11:55 GMT
  13.  
  14. dspencer@mproj.retix.com (David Spencer) writes:
  15.  
  16. > I've never understood why the second arg to completing-read, 'TABLE',
  17. > is an alist.  As far as I can tell, the cdr's of each element are
  18. > not used, so why not just make it a list of strings?
  19.  
  20. I think i know the, or at least an, answer to this one.
  21.  
  22. Completing read takes a vector of symbols as well as an alist.  The
  23. vector serves as the flat table format, handy for those times when
  24. you're dealing with, eg, the elisp obarray.  Given a match in the
  25. obarray, you obtain an associated value via a suitable symbol lookup
  26. function (eg, symbol-{value,function}), or whatever custom relation
  27. you prefer.
  28.  
  29. Alists are suited to those purposes where the value is encoded in the
  30. table.  You get the value once you have the key via the assoc and assq
  31. functions...
  32.  
  33. I've been messing with the completion functions, extending intrinsic
  34. minibuffer completion for incremental, in-the-minibuffer candidate
  35. displays.  The seemingly arbitrary completion functions wind up
  36. covering all the bases pretty nicely.
  37.  
  38. Ken
  39. klm@nist.gov, 301 975-3539
  40.