[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Philip Kaludercic
Subject: Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
Date: Wed, 21 Apr 2021 09:20:24 +0000

Here is an updated version, not with improved visuals:

Attachment: selecting-read.el
Description: application/emacs-lisp

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

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
  "Translation interface for `completing-read' to `selecting-read'.
DEFAULT are all interpreted as by `completing-read'."
  (or (selecting-read (all-completions "" collection predicate)
                      :must-select (not (memq require-match
                      :initial-query initial-input
                      :prompt prompt)
      (cond ((listp default) (car default))
            ((null 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]