Re: Adding the `prescient` packages to NonGNU ELPA?

[Okamsn <okamsn@protonmail.com>]

On 2022-11-20 09:24 UTC, Philip Kaludercic wrote:
> Okamsn <okamsn@protonmail.com> writes:
>
>> Hello,
>
> Hi,
>
>> Would you be willing to add Prescient[1] and some of its related
>> packages to NonGNU ELPA, as in the attached file? I am one of the
>> maintainers of this package. The author of the package does not wish to
>> assign copyright or require others to do so, so it cannot be added to
>> GNU ELPA.
>>
>> Prescient is for sorting and filtering completion candidates. Its
>> filtering is similar to the package Orderless and it sorts by a
>> combination of the frequency and the recency of the candidates.
>
>  From what I recall, Vertico does that too, but Vertico is a completion
> front-end?  Intuitively I would have also guessed that the front-end is
> the right place to solve this problem.
>
> Or maybe to rephrase the question, what does this package provide over
> vertico + orderless?

With Vertico's default sorting, the recency is unique to each command.
Prescient remembers the selected candidates for all completion commands,
using their recency and frequency to create a ranking of that candidate
for all commands in which they're shown.

With Prescient, one can select a candidate in one command and have it be
suggested for another command, such as inserting a candidate with
Company and later having it suggested near the top of the list when
calling `describe-variable` in Vertico. Candidates that are used more
frequently are ranked higher. If candidates haven't been used recently,
they eventually have their rankings forgotten.

There are other smaller differences, such as that, because Prescient can
provide both sorting and filtering, it can sort fully matched candidates
before partially matched candidates.

>
>> These are the packages I am wondering if you would be willing to add:
>>
>> - `prescient`: The base package, which provides the sorting and
>>      filtering functions and a completion style
>>
>> - `company-prescient`: Use `prescient` sorting with Company
>>
>> - `corfu-prescient`: Use `prescient` sorting and filtering with Corfu
>>
>> - `vertico-prescient`: Use `prescient` sorting and filtering with Vertico
>
> Could you explain the need for these other packages?  If we are talking
> about a completion style, why do other packages require their own
> support?

Prescient does not provide a completion UI.  Instead, there are packages
to set it up for completion UIs. It is not just a completion style
(which was only added recently, years after the filtering functions). To
use the sorting, one must also configure their chosen UI and set up a
way to make Prescient remember the selected candidate. The packages set
up this sorting in addition to the filtering.

I tried using modification of the completion metadata for sorting,
similar to the `flex` style, but it was decided that it is better to
keep the filtering and sorting more separate.  For example, to still be
able to sort the candidates filtered by other completion styles.

Because the integrations are UI specific, they are kept as separate
packages.

>
>> All of these packages live in the same repository in the link below.
>
> Would it be possible to change this?  E.g. by making each project live
> on it's own branch.  That would make the :ignored-files rules below a
> lot simpler.

I wouldn't mind making new branches that hold the stable versions. Are
you OK with the README and CHANGELOG still being duplicated in that case?

For the development/main version in the "main" branch, I don't want to
change how the author has set up the repository, since they still use it.

In this setup, the `:branch` property would be "main" and the
`:release-branch` property would be something like
"nongnu-elpa/prescient", yes?

Is the GNU ELPA README stating that it wants the version number to be
updated during every commit in the development branch? In that case,
maybe I could find a way to make GitHub update the development version
number in a separate branch.

>> When I tried testing the installation of `prescient`, it installed
>> an older version of the file `prescient.el` than what is current in the
>> repository. This was the version that received an update to the version
>> number, but how does the system decide which is the most recent stable
>> version of a file? I might need to increase the number to make it
>> install a newer version.
>
> Yes, ELPA finds the last commit that changed the version header and uses
> that to prepare a release.

OK. I will try updating the version number to make sure that was the
problem.