TRICKS to achieve higher level stuff with what CLIPCODE allows
==============================================================

-Arbitrary length lists:
 This was a requirement for doing various things in MMSS, for
 example lists of text blocks in a page, lists of anchors in
 a nav box, etc etc.
 One approach would be to have your list held just by one key,
 and have all the elements of the list together as the value,
 separated by spaces. You could then do something like
  for ELEMENT in `clipcode -r file listkey` ;do process $ELEMENT; done
 ... but then we see that this has a few problems, such as the
 fact that you've just restricted what characters can be in each
 element (no spaces, duh), and that if you want to have multiple
 fields per element, they can't be so easily associated.

 So the obvious answer was having the list covered by several keys,
 one (per field) per element, plus maybe some keys of metadata
 to control this high-level datatype. Hmm, but then how can you
 easily process this in the above style? At which point I remembered
 some of those obscure little text-processing utilities, including
   seq.
 Hence:
    listarity: 2                     #list entries have 2 fields
    listextents: 5 fielda fieldb     # list has 5 elements, and the
                                     #fields fielda and fieldb.
    listfielda1:value
    listfieldb1:value
    listfielda2:value
    listfieldb2:value
    listfielda3:value
    listfieldb3:value
    listfielda4:value
    listfieldb4:value
    listfielda5:value
    listfieldb5:value
  To get length: clipcode -r file listextents|cut -d " " -f 1
  To get 1st field: clipcode -r file listextents|cut -d " " -f 2
  To get 2nd field: clipcode -r file listextents|cut -d " " -f 3
  ... Or perhaps the length could be the last item, in which case
  it would be  clipcode -r file listextents|cut -d " " -f expr `clipcode -r file listarity` + 1 
  or something...  perhaps instead the fields should be
  listarity, listlength, and listfields. Or listdims and listfields.
  There could perhaps be a key
    listfieldatype:   to qualify what can go in that field.
  Most importantly:
    for ELEM in `seq [lengthgotbove]` ; do clipcode -r file listfielda$ELEM&&echo;clipcode -r file listfieldb$ELEM&&echo ;done
  ...flexible, hmm?
  For the purposes of *generic* editor scripts for dealing with these things,
   we should have a key named
     listIsAHLList:list
   which tells such a script to consider listarity and listextents to
   be control files for a high level list named "list". Having found
   such a key, it should not display the associated keys separately.
  Domain-specific editors should *know* what fields they require, of
  course, but should be able to spot lists of this sort too (for
  cases where the config file is newer than the editor).


