From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Okamsn Newsgroups: gmane.emacs.devel Subject: Re: Adding the `prescient` packages to NonGNU ELPA? Date: Sun, 20 Nov 2022 17:42:45 +0000 Message-ID: <4a52210d-3e39-ed34-a7c9-c3ee6e2a7a68@protonmail.com> References: <16193c73-ab80-04c9-558f-d5e6142f38f3@protonmail.com> <871qpydllo.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26682"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 20 18:53:58 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1owoVy-0006kn-2V for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Nov 2022 18:53:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1owoV3-0008UN-DF; Sun, 20 Nov 2022 12:53:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owoLM-0007Om-HN for emacs-devel@gnu.org; Sun, 20 Nov 2022 12:43:00 -0500 Original-Received: from mail-4316.protonmail.ch ([185.70.43.16]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owoLK-0002qf-AX for emacs-devel@gnu.org; Sun, 20 Nov 2022 12:43:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1668966175; x=1669225375; bh=gurER9UaN+ZIy7p2fI28CYKGLDtGtp6h1bmDLT7J6uM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=l5EYdknk9IVxcG4qRoEW0hhuf2yoUKN8Pss90BO75/ck75RXDgastoOUzrfTRKN4X WRq7z0Cvav2zsoe/X9MUAK4bxvWX7d3EvqMPXMf3WinLZSue6dG5MYQ/5vYkUHOCS0 nha8RXuuJc2i4PyN8g4uZteqFr2MsVZlLlwQPywHFhlmDNEZ0VTWktZDCPnP/YbZG2 0mbqvIcTRJp/5ylVOW/Jx2VAHfKj0C/ebk4Nf4vOillMUS3rEN3zrIOhm9zBMvkEbE nQ96QS1kkhi1eTMlj1SBdh/r28uPjsYrMrzGBDs/hWrKvriCZwmZ3lnRRCpJRHGQgv D/zeUWrwEPoIg== In-Reply-To: <871qpydllo.fsf@posteo.net> Feedback-ID: 25935600:user:proton Received-SPF: pass client-ip=185.70.43.16; envelope-from=okamsn@protonmail.com; helo=mail-4316.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 20 Nov 2022 12:53:00 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300260 Archived-At: On 2022-11-20 09:24 UTC, Philip Kaludercic wrote: > Okamsn 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 Vertic= o > > 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.