unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Adding the `prescient` packages to NonGNU ELPA?
@ 2022-11-20  3:27 Okamsn
  2022-11-20  9:24 ` Philip Kaludercic
  0 siblings, 1 reply; 16+ messages in thread
From: Okamsn @ 2022-11-20  3:27 UTC (permalink / raw)
  To: emacs-devel

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

Hello,

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.

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

All of these packages live in the same repository in the link below.

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.

Thank you.


[1]: https://github.com/radian-software/prescient.el

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-First-attempt-at-adding-packages.patch --]
[-- Type: text/x-patch; name=0001-First-attempt-at-adding-packages.patch, Size: 2507 bytes --]

From f2d4107036e5be8b97de83663e47aeb5a670a301 Mon Sep 17 00:00:00 2001
From: okamsn <okamsn@protonmail.com>
Date: Sat, 19 Nov 2022 21:13:05 -0500
Subject: [PATCH] First attempt at adding packages.

---
 elpa-packages | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index eb69320ee2..a15d60370b 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -484,6 +484,46 @@
  ("popup"		:url "https://github.com/auto-complete/popup-el"
   :ignored-files ("LICENSE"))
 
+ ("prescient"           :url "https://github.com/radian-software/prescient.el"
+  :branch "main"
+  :news "CHANGELOG.md"
+  :mainfile "prescient.el"
+  :readme "README.md"
+  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
+                  "corfu-prescient.el" "ivy-prescient.el" "scripts"
+                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
+                  ".dir-locals.el" ".github" ".gitignore"))
+
+ ("vertico-prescient"   :url "https://github.com/radian-software/prescient.el"
+  :branch "main"
+  :news "CHANGELOG.md"
+  :mainfile "vertico-prescient.el"
+  :readme "README.md"
+  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
+                  "corfu-prescient.el" "ivy-prescient.el" "prescient.el"
+                  "scripts" "selectrum-prescient.el" "stub" ".dir-locals.el"
+                  ".github" ".gitignore"))
+
+ ("corfu-prescient"     :url "https://github.com/radian-software/prescient.el"
+  :branch "main"
+  :news "CHANGELOG.md"
+  :mainfile "corfu-prescient.el"
+  :readme "README.md"
+  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
+                  "ivy-prescient.el" "prescient.el" "scripts"
+                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
+                  ".dir-locals.el" ".github" ".gitignore"))
+
+ ("company-prescient"   :url "https://github.com/radian-software/prescient.el"
+  :branch "main"
+  :news "CHANGELOG.md"
+  :mainfile "company-prescient.el"
+  :readme "README.md"
+  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "corfu-prescient.el"
+                  "ivy-prescient.el" "prescient.el" "scripts"
+                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
+                  ".dir-locals.el" ".github" ".gitignore"))
+
  ("projectile"  	:url "https://github.com/bbatsov/projectile"
   :ignored-files ("LICENSE" "doc" "test")
   :news "CHANGELOG.md")
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-20  3:27 Adding the `prescient` packages to NonGNU ELPA? Okamsn
@ 2022-11-20  9:24 ` Philip Kaludercic
  2022-11-20 11:23   ` Stefan Kangas
                     ` (3 more replies)
  0 siblings, 4 replies; 16+ messages in thread
From: Philip Kaludercic @ 2022-11-20  9:24 UTC (permalink / raw)
  To: Okamsn; +Cc: emacs-devel

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?

> 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?

> 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.

> 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.

> Thank you.
>
>
> [1]: https://github.com/radian-software/prescient.el
>
> From f2d4107036e5be8b97de83663e47aeb5a670a301 Mon Sep 17 00:00:00 2001
> From: okamsn <okamsn@protonmail.com>
> Date: Sat, 19 Nov 2022 21:13:05 -0500
> Subject: [PATCH] First attempt at adding packages.
>
> ---
>  elpa-packages | 40 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index eb69320ee2..a15d60370b 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -484,6 +484,46 @@
>   ("popup"		:url "https://github.com/auto-complete/popup-el"
>    :ignored-files ("LICENSE"))
>  
> + ("prescient"           :url "https://github.com/radian-software/prescient.el"
> +  :branch "main"
> +  :news "CHANGELOG.md"
> +  :mainfile "prescient.el"
> +  :readme "README.md"
> +  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
> +                  "corfu-prescient.el" "ivy-prescient.el" "scripts"
> +                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
> +                  ".dir-locals.el" ".github" ".gitignore"))
> +
> + ("vertico-prescient"   :url "https://github.com/radian-software/prescient.el"
> +  :branch "main"
> +  :news "CHANGELOG.md"
> +  :mainfile "vertico-prescient.el"
> +  :readme "README.md"
> +  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
> +                  "corfu-prescient.el" "ivy-prescient.el" "prescient.el"
> +                  "scripts" "selectrum-prescient.el" "stub" ".dir-locals.el"
> +                  ".github" ".gitignore"))
> +
> + ("corfu-prescient"     :url "https://github.com/radian-software/prescient.el"
> +  :branch "main"
> +  :news "CHANGELOG.md"
> +  :mainfile "corfu-prescient.el"
> +  :readme "README.md"
> +  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
> +                  "ivy-prescient.el" "prescient.el" "scripts"
> +                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
> +                  ".dir-locals.el" ".github" ".gitignore"))
> +
> + ("company-prescient"   :url "https://github.com/radian-software/prescient.el"
> +  :branch "main"
> +  :news "CHANGELOG.md"
> +  :mainfile "company-prescient.el"
> +  :readme "README.md"
> +  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "corfu-prescient.el"
> +                  "ivy-prescient.el" "prescient.el" "scripts"
> +                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
> +                  ".dir-locals.el" ".github" ".gitignore"))
> +
>   ("projectile"  	:url "https://github.com/bbatsov/projectile"
>    :ignored-files ("LICENSE" "doc" "test")
>    :news "CHANGELOG.md")



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-20  9:24 ` Philip Kaludercic
@ 2022-11-20 11:23   ` Stefan Kangas
  2022-11-20 15:19     ` Stefan Monnier
  2022-11-20 17:10   ` Visuwesh
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 16+ messages in thread
From: Stefan Kangas @ 2022-11-20 11:23 UTC (permalink / raw)
  To: Philip Kaludercic, Okamsn; +Cc: emacs-devel

Philip Kaludercic <philipk@posteo.net> writes:

>> 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.

We could also make the rules simpler by adding support for the inverse
of :ignored-packages.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-20 11:23   ` Stefan Kangas
@ 2022-11-20 15:19     ` Stefan Monnier
  2022-11-20 15:41       ` Philip Kaludercic
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2022-11-20 15:19 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Philip Kaludercic, Okamsn, emacs-devel

Stefan Kangas [2022-11-20 03:23:09] wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
>>> 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.
>
> We could also make the rules simpler by adding support for the inverse
> of :ignored-packages.

Multi-package repositories are fundamentally incompatible with
`package-vc` (they kind of work, but with various caveats).
So I think we definitely don't want to support them better, but instead
we should discourage them.  If we want to invest efforts in that
direction it should be efforts to make it easier to "re-merge" packages
so as to move away from the problem.


        Stefan




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-20 15:19     ` Stefan Monnier
@ 2022-11-20 15:41       ` Philip Kaludercic
  2022-11-21 21:17         ` Richard Stallman
  0 siblings, 1 reply; 16+ messages in thread
From: Philip Kaludercic @ 2022-11-20 15:41 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Stefan Kangas, Okamsn, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Stefan Kangas [2022-11-20 03:23:09] wrote:
>> Philip Kaludercic <philipk@posteo.net> writes:
>>>> 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.
>>
>> We could also make the rules simpler by adding support for the inverse
>> of :ignored-packages.
>
> Multi-package repositories are fundamentally incompatible with
> `package-vc` (they kind of work, but with various caveats).

They will have the same issues as elpa-admin has, right?  In that case,
the issue will be if someone just wants to install prescient, they will
have all the other dependencies unconditionally "installed" along with
the rest.  At the same time, if someone installs one of the more
specialised packages, which adds the same repository as a dependency,
you'll have the same package checked out twice, and I would have to
guess which takes priority in `load-path'...

> So I think we definitely don't want to support them better, but instead
> we should discourage them.  If we want to invest efforts in that
> direction it should be efforts to make it easier to "re-merge" packages
> so as to move away from the problem.

Agreed.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-20  9:24 ` Philip Kaludercic
  2022-11-20 11:23   ` Stefan Kangas
@ 2022-11-20 17:10   ` Visuwesh
  2022-11-20 18:39     ` Stefan Monnier
  2022-11-20 17:42   ` Okamsn
  2022-11-22 15:41   ` Jonas Bernoulli
  3 siblings, 1 reply; 16+ messages in thread
From: Visuwesh @ 2022-11-20 17:10 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: Okamsn, emacs-devel

[ஞாயிறு நவம்பர் 20, 2022] Philip Kaludercic wrote:

>> [...]
>> 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?

AFAIU, it is because there is no common way to call a function after
ending a completing-read and/or completion-in-region call so we end up
needing a UI specific way to do so.  The function records the selected
candidate, necessary for fuzzy(?) matching based on frequency and
recency ("frecency").
The README does a better job at explaining this than I do here (which is
based on understanding on how the package worked before it underwent
extensive rewrite).




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-20  9:24 ` Philip Kaludercic
  2022-11-20 11:23   ` Stefan Kangas
  2022-11-20 17:10   ` Visuwesh
@ 2022-11-20 17:42   ` Okamsn
  2022-11-22 15:41   ` Jonas Bernoulli
  3 siblings, 0 replies; 16+ messages in thread
From: Okamsn @ 2022-11-20 17:42 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: emacs-devel

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.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-20 17:10   ` Visuwesh
@ 2022-11-20 18:39     ` Stefan Monnier
  0 siblings, 0 replies; 16+ messages in thread
From: Stefan Monnier @ 2022-11-20 18:39 UTC (permalink / raw)
  To: Visuwesh; +Cc: Philip Kaludercic, Okamsn, emacs-devel

> AFAIU, it is because there is no common way to call a function after
> ending a completing-read and/or completion-in-region call so we end up
> needing a UI specific way to do so.  The function records the selected
> candidate, necessary for fuzzy(?) matching based on frequency and
> recency ("frecency").

Hmm.. indeed we have no way in the framework to let the UI tell the
completion-table or the completion-style which candidate was chosen in
the end.  The closest we have is the history variables (and that's only
available for minibuffer completions).
:-(


        Stefan




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-20 15:41       ` Philip Kaludercic
@ 2022-11-21 21:17         ` Richard Stallman
  2022-11-22 13:53           ` Akib Azmain Turja
  0 siblings, 1 reply; 16+ messages in thread
From: Richard Stallman @ 2022-11-21 21:17 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: monnier, stefankangas, okamsn, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

People are talking about something called "prescient".  What is it?
What jobs does it do?  Is there a drawback in these jobs?  If those
topics were discussed, I did not see it.  But they are the most important
questions about that something,

The discussion is focusing on practical issues of merging them, but we
should also think about whether the presence of this facility has any
drawbacks.

Perhaps "prescient" is just "more of the same," convenient features
with no deep implications.  Let's have a discussion of what it does,
so we can see whether that is true or not.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-21 21:17         ` Richard Stallman
@ 2022-11-22 13:53           ` Akib Azmain Turja
  2022-11-23 23:12             ` okamsn
  0 siblings, 1 reply; 16+ messages in thread
From: Akib Azmain Turja @ 2022-11-22 13:53 UTC (permalink / raw)
  To: Richard Stallman
  Cc: Philip Kaludercic, monnier, stefankangas, okamsn, emacs-devel

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

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> People are talking about something called "prescient".  What is it?
> What jobs does it do?  Is there a drawback in these jobs?  If those
> topics were discussed, I did not see it.  But they are the most important
> questions about that something,
>
> The discussion is focusing on practical issues of merging them, but we
> should also think about whether the presence of this facility has any
> drawbacks.
>
> Perhaps "prescient" is just "more of the same," convenient features
> with no deep implications.  Let's have a discussion of what it does,
> so we can see whether that is true or not.

Prescient is sorting and filter packages for completion UIs.  It sorts
candidates using frecency (frequency and recency).  For example, if you
select 'grep' in your M-x prompt using one of the supported UIs, 'grep'
will be placed earlier among the candidates next time.  If you use
another supported auto-completion UI like Company or Corfu, Prescient
will use the data it gathered from other UIs to sort the candidates.

It does the sorting and filtering with some simple algorithms, so I
don't think it has any implications.

[ Disclaimer: I longer use Prescient, so this might be outdated. ]

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-20  9:24 ` Philip Kaludercic
                     ` (2 preceding siblings ...)
  2022-11-20 17:42   ` Okamsn
@ 2022-11-22 15:41   ` Jonas Bernoulli
  2022-11-22 21:09     ` Stefan Monnier
  3 siblings, 1 reply; 16+ messages in thread
From: Jonas Bernoulli @ 2022-11-22 15:41 UTC (permalink / raw)
  To: Philip Kaludercic, Okamsn; +Cc: emacs-devel

Philip Kaludercic <philipk@posteo.net> writes:

>> 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.

When making such requests, we should think about the needs of all
involved parties.  We all have our own ideas of "best practices"
and sometimes these ideas are in conflict with each other and/or
convenience.

For the maintainers of a "main package" with "extension packages", it is
most convenient to keep these packages in a single repository; making
changes across more than one of the packages is easier that way.  Since
they work on these packages the most, their needs should come first, and
as far as I can tell, nobody tries to *force* them to do something else.

For most users it doesn't matter much.  [Non]GNU Elpa and Melpa take
care of distributing the extension packages separately, making sure that
users do not have to install any additional packages, which are only
needed by one of the extensions, unless they actually want to use those.

For Melpa it is trivial to split a repository into multiple packages.

[Non]GNU Elpa take a different approach when it comes to deciding which
files to include in package tarballs.  Where Melpa excludes everything
except certain files, [Non]GNU Elpa include everything except certain
files.  (I might be wrong about this, but I believe) [Non]GNU Elpa do
not have a default exclude list used for all packages.  As a
consequence, and even though they include more files, I believe their
file specifications tend to be more verbose.  [I don't intend to argue
here for one approach or the other, that isn't the question here.]

People involved in [Non]GNU Elpa pushing back harder against putting
extensions in the same repository as the main package than the Melpa
folks, is probably an indicator that dealing with such bundling is more
work for them.

But AFAIK it cannot be *that* much more work, that it would justify by
itself, to ask package maintainers to take on even more additional work
by splitting up their repositories, and to implying in those requests
that doing so is a best practice that will benefit everyone.

If package maintainers are willing to split up their repositories, even
though it means more work for them, that is fine by me.  (Here too, it
isn't *that* much additional work, and I agree that if we all had
infinite time, this clearly would be the best way of doing it.)  But I
don't think splitting things up to the extreme should be described as an
unquestionable best practice; after all emacs.git itself bundles a lot
of unrelated packages in the same repository.  [Off topic and maybe a
bit surprising: I would be in favor of splitting up emacs.git more, but
let's not get into that here.]

I should note that I am aware that the work is not done by once writing
the file include/exclude rules when the multiple packages that are
maintained in a single repository are first added.  The later addition
of yet another library/package can make it necessary to adjust those
existing rules.  But I don't think this is a huge burden and that it is
small compared to the additional work that you are asking package
maintainers to take on by splitting up their repositories.

Another drawback of main+extension repositories from the perspective of
[Non]GNU Elpa is that it makes it necessary for elpa-admin.el to
checkout the same repository multiple times.  I think this is a small
drawback and I would recommend that just ignore it.  Otherwise it is an
internal tooling issue that shouldn't concern package maintainers;
elpa-admin.el could, for example, be taught to clone the repository just
once and to use a separate worktree for each package.

Moving to another interested party, the Emacsmirror, which I maintain.
The Emacsmirror provides a superset of the packages in any one of the
elpas, or all elpas taken together for that matter.  A consequence of
that is that it has to deal with a lot more diverging practices, and
that the various elpas promote in some cases competing best practices.

Also, because the benefits of the Emacsmirror are less obvious I am in
a weaker position when requesting changes from packages maintainers,
compared to people maintaining an elpa.  But since we are nevertheless
in a similar boat, I appreciate it, when the maintainers of the elpas
take the needs of the Emacsmirror into account.

The Emacsmirror itself does not even attempt splitting up repositories
that contain multiple packages.  It mirrors repositories.  Ideally one
repository contains one package, but that isn't always the case and
trying to change it would be an uphill battle, which could never be won.
I have been fighting some other uphill battles for years, but ultimately
I often have no choice but to accept that package maintainers do things
that I think are not ideal or even wrong.

Nowadays, for the most part, the Emacsmirror learns about new packages
to mirror, by importing the lists of package recipes/specifications of
the various elpas.  Because the elpas do sometimes build multiple
packages from a single repository, duplicates appear in those lists
(from the mirror's perspective) and I have to make sure to not add the
same repository twice.

This is where this recommendation becomes problematic:

> E.g. by making each project live on it's own branch.

The current Emacsmirror code cannot deal with this special case.  It
wouldn't be hard to support it, but so far I had no reason to implement
that.  There is *a single* package that currently does this (as a result
of Stefan Monnier asking its maintainer to do so).

The Straight package manager apparently cannot deal with this either.  I
would assume that it wouldn't be hard to implement support, but here too
it does not make much sense to do so for the benefit of a single package
that wants to do things differently.

My own package manager, Borg, follows the lead of the Emacsmirror.  It
clones the main-package+extensions repository as-is.  Users have to
explicitly exclude the extensions that they are not interested in, or
they get compilation errors.  This might sound not very user-friendly to
those who don't use Borg, but in practice it works well; Borg is just
more picky about who its friends are (but that isn't the topic here).

As I have said before, I agree that ideally extensions to a main package
would be maintained in separate repositories, but also that this means
more work for the maintainers, and if they don't want to do it because
of that, then that should be accepted.

I have one additional request: When you encourage package maintainers to
split up their repositories, then do NOT recommend that they put the
separate packages into separate branches of the SAME repository.

Instead ask them to use separate repositories altogether.  Except for
the small additional initial need to create the separate repositories,
this should not be any more work than using merely separate branches.

Merely using separate branches is a half measure, that doesn't really
benefit anyone.  Various tools that deal with emacs packages currently
don't support it.  Setting up the branches requires knowing or learning
about orphan branches.  Checking out multiple packages requires either
cloning the same repository multiple times, or knowing or learning how
to use multiple worktrees.

     Jonas



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-22 15:41   ` Jonas Bernoulli
@ 2022-11-22 21:09     ` Stefan Monnier
  2022-11-23  9:56       ` Jonas Bernoulli
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2022-11-22 21:09 UTC (permalink / raw)
  To: Jonas Bernoulli; +Cc: Philip Kaludercic, Okamsn, emacs-devel

> Another drawback of main+extension repositories from the perspective of
> [Non]GNU Elpa is that it makes it necessary for elpa-admin.el to
> checkout the same repository multiple times.  I think this is a small
> drawback and I would recommend that just ignore it.  Otherwise it is an
> internal tooling issue that shouldn't concern package maintainers;
> elpa-admin.el could, for example, be taught to clone the repository just
> once and to use a separate worktree for each package.

Agreed.

The real reason behind the pushback is when trying to support "install
from VCS", such as `package-vc` (which is also supported by
`elpa-admin.el`, tho in less user-friendly way).

E.g. I can't see a clean way to install `git-commit` directly from its
VCS (i.e. recognized by `package-activate-all` and running from the Git
clone) without either forcing the install of `magit` at the same
time(&place) and/or having side-effects like sometimes shadowing another
installation of `magit`.

We may be able to handle it satisfactorily *if* the various subpackages
are each placed in a different subdirectory (and indeed, in that case,
depending on the VCS we may even be able to clone only the relevant
subdir (or maybe clone the whole, but make a worktree that only exposes
the relevant subdir)).


        Stefan "I care about that because that's the way I've installed
                all my packages for the last few years and I find it very
                convenient :-)"




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-22 21:09     ` Stefan Monnier
@ 2022-11-23  9:56       ` Jonas Bernoulli
  2022-11-23 12:33         ` Stefan Monnier
  0 siblings, 1 reply; 16+ messages in thread
From: Jonas Bernoulli @ 2022-11-23  9:56 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Philip Kaludercic, Okamsn, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> E.g. I can't see a clean way to install `git-commit` directly from its
> VCS (i.e. recognized by `package-activate-all` and running from the Git
> clone) without either forcing the install of `magit` at the same
> time(&place) and/or having side-effects like sometimes shadowing another
> installation of `magit`.

I see what you did there. ;)

This is an unusual, and in a sense extreme, example.  Prescient is a
much more typical example, so if you want to discuss the negative effect
that such practices have on your workflow, then it would be better to
focus on that package.

git-commit/magit also has an unpleasant backstory.  I can tell you about
that in a private message.  All I'll say here is that I did not actually
want to add git-commit to magit but the behavior of its author forced me
to accept the offer to take over as maintainer.  At the time it seemed
best to do that by adding it to the magit repository.

Moving it to a separate repository is an option.

At this time there aren't many changes that touch it, as well as other
parts of the repository, so the cost would probably be pretty low, and
I have done the same for with-editor and magit-popup (now replaced by
transient) before.

On the other hand, I have some doubts this is actually going to benefit
anyone.  Is there anyone out there who does use git-commit but not
magit?



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-23  9:56       ` Jonas Bernoulli
@ 2022-11-23 12:33         ` Stefan Monnier
  0 siblings, 0 replies; 16+ messages in thread
From: Stefan Monnier @ 2022-11-23 12:33 UTC (permalink / raw)
  To: Jonas Bernoulli; +Cc: Philip Kaludercic, Okamsn, emacs-devel

>> E.g. I can't see a clean way to install `git-commit` directly from its
>> VCS (i.e. recognized by `package-activate-all` and running from the Git
>> clone) without either forcing the install of `magit` at the same
>> time(&place) and/or having side-effects like sometimes shadowing another
>> installation of `magit`.
[...]
> This is an unusual, and in a sense extreme, example.

FWIW, I have no idea whether it's usual or not and what's its history.

> Prescient is a much more typical example,

I don't know in which way the situation is different for Prescient.

> git-commit/magit also has an unpleasant backstory.  I can tell you about
> that in a private message.  All I'll say here is that I did not actually
> want to add git-commit to magit but the behavior of its author forced me
> to accept the offer to take over as maintainer.  At the time it seemed
> best to do that by adding it to the magit repository.

But that makes no difference to the problem at hand: by being in the
same directory as the other `magit` files, you can't add it to
`load-path` without adding those other files as well.

> On the other hand, I have some doubts this is actually going to benefit
> anyone.  Is there anyone out there who does use git-commit but not magit?

This cuts both ways: if they're always installed in pair, why not keep
them as a single package?


        Stefan




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-22 13:53           ` Akib Azmain Turja
@ 2022-11-23 23:12             ` okamsn
  2022-11-26  0:50               ` Richard Stallman
  0 siblings, 1 reply; 16+ messages in thread
From: okamsn @ 2022-11-23 23:12 UTC (permalink / raw)
  To: Akib Azmain Turja, Richard Stallman
  Cc: Philip Kaludercic, monnier, stefankangas, emacs-devel

On 2022-11-22 13:53 UTC, Akib Azmain Turja wrote:
> Richard Stallman <rms@gnu.org> writes:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>> People are talking about something called "prescient".  What is it?
>> What jobs does it do?  Is there a drawback in these jobs?  If those
>> topics were discussed, I did not see it.  But they are the most important
>> questions about that something,
>>
>> The discussion is focusing on practical issues of merging them, but we
>> should also think about whether the presence of this facility has any
>> drawbacks.
>>
>> Perhaps "prescient" is just "more of the same," convenient features
>> with no deep implications.  Let's have a discussion of what it does,
>> so we can see whether that is true or not.
>
> Prescient is sorting and filter packages for completion UIs.  It sorts
> candidates using frecency (frequency and recency).  For example, if you
> select 'grep' in your M-x prompt using one of the supported UIs, 'grep'
> will be placed earlier among the candidates next time.  If you use
> another supported auto-completion UI like Company or Corfu, Prescient
> will use the data it gathered from other UIs to sort the candidates.
>
> It does the sorting and filtering with some simple algorithms, so I
> don't think it has any implications.
>
> [ Disclaimer: I longer use Prescient, so this might be outdated. ]
>

This description is accurate.




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Adding the `prescient` packages to NonGNU ELPA?
  2022-11-23 23:12             ` okamsn
@ 2022-11-26  0:50               ` Richard Stallman
  0 siblings, 0 replies; 16+ messages in thread
From: Richard Stallman @ 2022-11-26  0:50 UTC (permalink / raw)
  To: okamsn; +Cc: akib, philipk, monnier, stefankangas, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Prescient is sorting and filter packages for completion UIs.  It sorts
  > > candidates using frecency (frequency and recency).  For example, if you
  > > select 'grep' in your M-x prompt using one of the supported UIs, 'grep'
  > > will be placed earlier among the candidates next time.  If you use
  > > another supported auto-completion UI like Company or Corfu, Prescient
  > > will use the data it gathered from other UIs to sort the candidates.
  > >
  > > It does the sorting and filtering with some simple algorithms, so I
  > > don't think it has any implications.

Thanks.  Now everyone reading the list can see what features you're
proposing to add.

I don't have any opinions about them myself.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2022-11-26  0:50 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-20  3:27 Adding the `prescient` packages to NonGNU ELPA? Okamsn
2022-11-20  9:24 ` Philip Kaludercic
2022-11-20 11:23   ` Stefan Kangas
2022-11-20 15:19     ` Stefan Monnier
2022-11-20 15:41       ` Philip Kaludercic
2022-11-21 21:17         ` Richard Stallman
2022-11-22 13:53           ` Akib Azmain Turja
2022-11-23 23:12             ` okamsn
2022-11-26  0:50               ` Richard Stallman
2022-11-20 17:10   ` Visuwesh
2022-11-20 18:39     ` Stefan Monnier
2022-11-20 17:42   ` Okamsn
2022-11-22 15:41   ` Jonas Bernoulli
2022-11-22 21:09     ` Stefan Monnier
2022-11-23  9:56       ` Jonas Bernoulli
2022-11-23 12:33         ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).