Giters

radian-software / selectrum

🔔 Better solution for incremental narrowing in Emacs.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[RFC] Moving Selectrum to GitHub Organization

raxod502 opened this issue · comments

commented

Note: this is basically the same as radian-software/straight.el#946, but just so people only have to read one issue, I've reproduced the same text with adjustments here.

I think it's high time that we move Selectrum from my personal GitHub account to a GitHub Organization. This has a few advantages:

  • Ability for co-authors such as @clemera, @minad, and @okamsn to fully manage the repository (e.g., administrative settings, adding other collaborators)
  • Access to more GitHub features (many things are gated behind putting a repository in an organization)
  • Easy way to grant access for collaborators to multiple related repositories, e.g. prescient.el along with Selectrum

I also have a personal interest in this. As some of you may know, in mid-2021, I received spurious legal threats from a former employer who felt personally offended about my open-source work. After consulting with a lawyer, I was told that the standard advice is to conduct open-source work as part of a single-member LLC, which is what I'm doing going forward. The idea is that if you are sued, then only the assets of the LLC can be subject to damages, rather than your personal savings. So, I have a GitHub Organization for the legal entity I've formed: radian-software.

On the bookkeeping side, here is what would change:

On the legal side, here is what would change:

  • My personal contributions will be transferred (by a legal contract I have on file) from me to Radian LLC
  • Everyone else's contributions remain their own, as before
  • Selectrum remains licensed under the MIT License and available under the same terms as before
  • If somebody else decides that my open-source work offends them, I don't have to be as scared of a lawsuit

I'll submit a pull request to MELPA updating the recipe, but even before that's done there shouldn't be any breakage, since GitHub handles repository renames transparently and allows you to still clone from the old location.

Overall, I think this change should have fairly minimal impact, both from a semantic perspective and from a technical one. But since Selectrum is a critical piece of many people's daily workflows with Emacs, I do want to put this out there for community review and comment before taking any action, and want to give people a chance to point out any problems that haven't occurred to me.

Definitely want to get the thoughts of @clemera / @minad / @okamsn here as well, since they've all done the vast majority of the work on Selectrum in the last year or two.

commented

Hello Radon,

I have a counter proposal. I hope you don't mind if I am direct.

I propose to deprecate Selectrum in favor of my Vertico package, which supersedes Selectrum in every way and which can be considered its successor [1]. This has multiple advantages:

  • Selectrum has technical flaws which are due to its design, which is not close enough to the basic Emacs completion machinery. All these issues are fixed by design in Vertico.
  • Supplementary packages like Consult or Marginalia have to maintain workarounds for Selectrum, which could be deprecated in the long term.
  • For the community and in particular for newcomers, the completion landscape would be simplified.
  • Selectrum got larger and larger over time such that it failed on delivering its initial objectives of having a small and simple system. Selectrum is now at 3000 lines which is in the same ballpark as Ivy. Vertico still stays at well below 1000 lines with essentially the same out of the box feature set. On top Vertico offers many optional extensions, which make it highly configurable.
  • We join development forces behind one project instead of scattering it across two which have essentially the same goals.
  • Any of the legal issues you mentioned are avoided since Vertico is assigned to the FSF. This holds as long as the FSF doesn't turn evil. ;)

I hope that you are open to this proposal. To be clear, I hadn't planned to create a "competitor" package. As you know, I contributed quite a bit to Selectrum for a while and was enthusiastic about it. Initially, Vertico was a prototype to fix the dynamic completion table issues and I had considered merging it back to Selectrum. Then it turned out that it would be easier to polish up Vertico to a full package in contrast to fixing Selectrum from the ground up. From my perspective, Vertico is essentially what Selectrum aimed to be.

I know that my response is probably not what you expected. Please let me know what you think and maybe I can address your concerns.

Daniel

[1] There is one detail - Vertico does not support Prescient yet, since Prescient is not a completion style. This should be fixable though and it should finally become possible to glue Vertico and Prescient together.

commented

I don't mind that, as long as existing features are supported! I haven't been keeping up with the completion ecosystem, so I wasn't aware of the newer developments.

Support for prescient.el is definitely a must for me, but I can help to get that work done. After we have feature parity, I'll try migrating my personal configuration (Radian) over to use Vertico instead of Selectrum, and if that goes well, then I'll see about writing up some migration directions for current users, and add a soft deprecation to Selectrum. I can tag you for review on that documentation.

In the meantime, I guess I can go ahead and move the repo like I suggested - sounds like if we're moving away from it going forward then there will be even less issue. Will wait some time for others to chime in though before I do anything.

commented

Thank you for you answer. I am glad that you didn't take it the wrong way. I am not opposed to moving this repository as you proposed. From my side, feel free to proceed.

There have indeed been a lot of recent developments, such that the new package set is well on par with Helm/Ivy (or even better in some aspects), while still staying faithful to the goal of having small and relatively simple components, which can be composed freely by the user.

I would go with the soft deprecation you mentioned if the migration works well for you. We should definitely wait for a while to hear other opinions. In particular, @okamsn contributed to both Selectrum and Prescient.

commented

I trust the judgment for moving the repositories.

On deprecating Selectrum in favor of Vertico, I'm not against that once Prescient supports being a completion style. I made a basic attempt at this in the branch at https://github.com/okamsn/prescient.el/tree/comp-style, but did not get far. I haven't tried to implement the altering of the sort function as mentioned by Minad in radian-software/prescient.el#120, which could be used to support prescient-sort-full-matches-first. The completion style has been low on my to-do list while I try to get my own package up to snuff. If someone else wants to take it on sooner, I'm fine with that.

commented

Filed melpa/melpa#8027 to update the MELPA recipe.