Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico

[Philip Kaludercic <philipk@posteo.net>]

[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

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.


[-- Attachment #2: selecting-read.el --]
[-- Type: application/emacs-lisp, Size: 6753 bytes --]