Philip Kaludercic writes: > It might therefore be necessary to actually implement a "selecting-read" > function, that could be used more or less like completing-read, but that > provides a better default UI not based around completing text but > actually selecting objects/items. I attached a primitive version of selecting-read to this message. The UI is horridly primitive, but the basic idea should be understandable. Using generic functions, methods can be defined determining how an object is handled. In this iteration, three generic functions are used: - (selecting-read-represent object) Return a string representing the object. This is the only necessary method. - (selecting-read-properties object) Return a plist denoting properties of the object - (selecting-read-children object) Return a list of children of this object It seems that these three functions are enough, and that adding more would risk becoming too complicated. When evaluating a nonsensical query like (selecting-read '((node "one" "one.1" "one.2" "one.3") (node ("two" :property "propertied" :key "value") "two.1" "two.2") "three")) a child window appears and the user can select an object, that selecting-read returns directly (eq). Additional arguments are passed as keywords. A simple example is :multiple that lets selecting-read give me a list of items that were marked (selecting-read '((node "one" "one.1\n" "one.2" "one.3") (node ("two" :property "propertied" :key "value") "two.1" "two.2") "three") :multiple t) Because I'm not just now primarily concerned with what completing-read might look like, it doesn't do "automatic narrowing" like Helm or Ivy. The framework I sketched here should be flexible enough to support something like that, if preferred. -- Philip K.