For the most part, the suggestion is the same, I just added an
additional generic function

           (selecting-read-flags object)

that returns a list of flags, to indicate if an object is selectable,
should be folded by default, etc.

As a demonstration, the option selecting-read-auto-narrow enabled a
behaviour that is similar to what selecting completion framework
provide.

I have also mentioned that a "translation function" could be written to
translate completing-read calls into selecting-read. Here is an example
that could be set to completing-read-function, even if it does not
implement the entire interface:

--8<---------------cut here---------------start------------->8---
(defun selecting-read-<-completing-read (prompt collection &optional
					       predicate
					       require-match
					       initial-input
					       _hist
					       default
					       _inherit-input-method)
  "Translation interface for `completing-read' to `selecting-read'.
PROMPT, COLLECTION, PREDICATE, REQUIRE-MATCH, INITIAL-INPUT and
DEFAULT are all interpreted as by `completing-read'."
  (or (selecting-read (all-completions "" collection predicate)
		      :must-select (not (memq require-match
					      '(confirm-after-completion
						confirm
						nil)))
		      :initial-query initial-input
		      :prompt prompt)
      (cond ((listp default) (car default))
	    ((null default) "")
	    (default))))
--8<---------------cut here---------------end--------------->8---

There are still issues, especially with large collections (try C-h o and
wait). When I get around to working on this again, I'll try to implement
the lazy selection generation, as mentioned before.

Philip Kaludercic <philipk@posteo.net> writes:

> Philip Kaludercic <philipk@posteo.net> 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.