Re: completing-read & emacsql

[Philip Kaludercic <philipk@posteo.net>]

Thanos Apollo <public@thanosapollo.org> writes:

> Hello Philip,

You seemed to have dropped emacs-devel, so I added it again.

> Is using a defcustom like this a valiable solution, for completing-read
> interactions?
>
> (defcustom gnosis-completing-read-function
>   (cond ((or (and (featurep 'vertico)
> 		  vertico-mode)
> 	     (and (featurep 'helm)
> 		  helm-mode))
> 	 'completing-read)
>         ((and (featurep 'ivy)
> 	      ivy-mode)
> 	 'ivy-completing-read)
>         (t 'ido-completing-read))
>   "Preferred `completing-read' function to use.
>
> Defaults to Vertico, Ivy or Helm if available and enabled,
> otherwise defaults to `ido-completing-read'."
>   :type 'function
>   :group 'gnosis)

I wouldn't say so, at least for people like me who want to avoid visual
noise (as Emacs does by default), all of the above are wrong.  I /want/
to use the default completion interface.

There is sadly a common mistake, in believing that `completing-read'
provides an interface for selecting strings, while the default interface
distinguishes between expansion of partial input and selecting from a
list of completion options.  To me, that is the reason why

  (completing-read "Select: " '(foo bar baz))

returns a string, and not a symbol.  The interface is reading textual
input while providing completion -- which by default doesn't have to be
any of the completion options!

There is no canonical interface I know of to select an s-expression from
a collection, but perhaps there should be, to avoid the need of misusing
`completing-read'.

>
> AFAIK ido-completing-read is built-in with Emacs, this should make the
> user intractions with gnosis more convenient with the default emacs
> behavior.
>
>
> Where can I look for the discussions that took place for emacsql
> inclusion in nongnu ELPA? I can see a github issue on emacsql repo, but
> searching for "Jonas Bernoulli emacsql" on the emacs-devel archive
> doesn't return anything.

Stefan Kangas (CC'ed) added the packages a little over a year ago,
perhaps he remembers?

> I could use the built-in sqlite implementation, but it would mean that I
> (might) have to change much of the current values of my current database
> or at least how they are outputted.
>
> If you were developing a package that was already built using emacsql,
> would you consider it worth the work to change it to the built in sqlite?

I don't know what the current emacsql situation is, so it would be worth
looking into to resolve why the package is currently only on -devel, at
least before you start rewriting stuff.