search

radian-software / selectrum

🔔 Better solution for incremental narrowing in Emacs.
MIT License
739 stars 33 forks source link

Could you consider your package to be included in GNU ELPA? #225

Closed gnusupport closed 4 years ago

gnusupport commented 4 years ago

Please let me know if you could consider including your package in GNU ELPA, so that it becomes generally available to Emacs users by default?

That would involve all developers to sign some papers. Other GNU ELPA packages could then build upon this package.

raxod502 commented 4 years ago

I have no problem with Selectrum being added to GNU ELPA. However, I am unwilling to assign my copyright for Selectrum, nor am I willing to collect such copyright assignments from my contributors. Therefore, inclusion would be subject to a change of policy on your end.

The same judgment applies to all of my other open-source work.

raxod502 commented 4 years ago

My projects may be better candidates for inclusion in the so-called "Non-GNU ELPA" project that I hear is being created, although I am not familiar with the details.

gnusupport commented 4 years ago

Any useful Emacs package may be included to non-GNU ELPA and authors or maintaners will have control if they want. If they do not want, packages will be included nevertheless.

I think you may close this issue.

gnusupport commented 4 years ago

I am not representing neither GNU nor FSF, so I cannot help on that. I understand the point. It means it will not be included in GNU ELPA.

There will be new ELPA on nongnu.org where useful packages will be included.

When package useful package is in GNU ELPA, it becomes so much easier for new packages to depend on such. In general I would like that narrowing comletion network is inside of Emacs.

raxod502 commented 4 years ago

Sounds good! I understand your point of view, it definitely is nice when packages are more easily accessible.

minad commented 4 years ago

@gnusupport While I also would like to see selectrum being used more widely, I am not sure if moving to closure upstream is a necessary requirement here. What I find more important is that the APIs offered by Emacs are made as such that packages like this work well and continue to do so. I am not sure if there is anything which needs to be done - but there seems to be quite some complexity around the completion framework. There is ido which appears in many places in the emacs code base, but does not integrate well with the completion framework. And selectrum seems to hook into quite a few places, maybe there are some warts which could be sorted out. For another example, when I recently tried multi-occur, it didn't work nicely with selectrum, since multi-occur uses the wrong apis internally (see #226). So I think these are the points where downstream projects like this matter a lot and could contribute back to upstream. Maybe @raxod502 would also be willing to contribute to that with his experiences - in contrast to giving up copyright, which I too find a questionable requirement.

gnusupport commented 4 years ago

Alright thank you.

You do not give up authorship or copyright neither control to FSF. That is assignment of copyrights so that FSF can protect the software on long term.

Software that is built-in into Emacs is useful as can be programmatically used by users without hassles of downloading or finding software. Don't you think that ivy, helm, selectrum or similar would be very useful to be a built-in library?

ido-mode is one way, it is horizontal and not quite visual such as vertical tools.

I am compering here various narrowing incremental search including external dmenu: https://gnu.support/images/2020/11/2020-11-06/2020-11-06-13:22:39.ogv

In my opinion accessibility and legibility is very important for users and not in the context of a simple text editor. Emacs is more like management of anything. Think of managing large sets of data by using incremental search. People need to focus and watch.

Helm eliminates TAB and replaces it with actions, as why should be tab there when completion is happening in real time? TAB is for single line completions. That approach is good.

Helm does not remove minibuffer, it is called minibuffer for a reason and then it suddenly jumps out, disappears in front of user for you-name completion package. Good approach is that minibuffer remains minibuffer as people entering data long time get used to minibuffer and not to jump around with stuff up-down. I hope you understand.

There are few important packages coming to GNU ELPA soon and such will influence creation of many other packages. For now, the only somehow usable completion package is Ivy and I am trying in general to make my software not be dependant on any completion package.

Keep up good work. Thank you.

minad commented 4 years ago

@gnusupport I am not involved with this project. In case you misunderstood this. I am as external to this project as you.

I also prefer the more limited scope of selectrum to something like ivy or helm. While I like many of the ideas promoted by those projects, I don't like that they change everything.

But I don't agree that things should move into upstream or necessarily have to move closer to upstream. I would rather advocate for removal of stuff from Emacs core, moving it to Elpa. Instead the focus should be on extensible APIs in the core. Basically my point is that there shouldn't be some package with first class status, like icomplete and ido, instead all of the completion packages should have the same standing.

gnusupport commented 4 years ago

Discussion is free software brings new ideas and influences software development to become more useful. Of course all the discussion is well aligned with: https://www.gnu.org/fun/jokes/users-lightbulb.html

I also prefer the more limited scope of selectrum to something like ivy or helm. While I like many of the ideas promoted by those projects, I don't like that they change everything.

I understand what you mean. Helm packages are many and helm will not change anything if user does not want. Same is with other completion packages.

Most important is that built-in completing-read function already offers ways of customizations and that people can build upon it. Narrowing incremental search is useful feature in many software programs. In my opinion everybody should start adopting it.

From view point of application development, let us say contact management, then it is more visible when lines are spread over all screen, not just in minibuffer or half-window. Yes, I am looking to find such feature well polished so that I may give applications to GNU ELPA.

But I don't agree that things should move into upstream or necessarily have to move closer to upstream. I would rather advocate for removal of stuff from Emacs core, moving it to Elpa.

Removing those packages that are common are also removing people's habits. For example I do expect that webjump is in Emacs, I would be surprised and feel disembodied if it would not be there. I am expecting that ping is built-in as I need to check remote hosts. Like eww I could not work without it. In general I am avoiding Javascript websites. newsticker and few IRC packages are built-in, it is my expectation to be able to run them and it comes from decades of using Emacs. Some programs and functions in customization files depend on those packages. Users would break their configuration if some of packages would be removed from Emacs.

Instead the focus should be on extensible APIs in the core. Basically my point is that there shouldn't be some package with first class status, like icomplete and ido, instead all of the completion packages should have the same standing.

There is no first class status especially not for ido or icomplete. How you get that impression?

It is up to people to propose and to include their software if they wish. Some people do it, some not, then people decide if to include it or not. Just because it was included that does not mean it is "first class".

What matters is that it is free software as part of Emacs and it is useful.

Recently I have heard icomplete was before ido but it is not as complete as ido, so for me that is reinventing the wheel. It does not matter who was first if there is already feature that does something well. I just do not know if I am faster with plain completion or with ido, I think with plain.

There are many packages not being part of Emacs and being useful. Packages that are part of Emacs influence Emacs users greatly as such are then described in the Emacs Manual and used and re-used over many years.

Well written built-in packages allow programmers to build upon them with less programming.

In my opinion Emacs requires menu system for selection from large collections. I have 15892 hyperlinks in knowledge management system. There are 195000 contacts, notes, files, emails and few thousand web pages and what else more.

Managing large collections of information requires visible easy to focus interface. It is basically menu system where only narrowing incremental search can help to pinpoint the piece of information.

minad commented 4 years ago

There is no first class status especially not for ido or icomplete. How you get that impression?

There is. For example if you look around in the emacs codebase, at some places there are special cases for ido. Icomplete does not really have first class support, except for being part of upstream. My point is more that things like this should be avoided, if things are already good, I am happy!

gnusupport commented 4 years ago

Sure, but then you tell to author who made that. What I understand it is code re-use. When something is built-in, then it will be rather reused. That is why I wold like ivy or any better completion to enter straight into Emacs.

raxod502 commented 3 years ago

my point is that there shouldn't be some package with first class status, like icomplete and ido,

Yeah, this gets a big +1 from me. Special cases in Emacs core for third-party packages is one of the bigger ecosystem problems. It seems like within Emacs core, there is no concept of modularity or separation of concerns: if a package is supported in Emacs core, it's just kind of a part of everything, instead of being a separate part that could be included or excluded freely. Ido and Icomplete are indeed some of the worst offenders. Isearch has a lot of random hooks throughout core, and perhaps the most egregious case is ElDoc, which has extensive explicit support for Company-specific features despite Company not even being a part of Emacs core (see elisp-mode.el.gz in the distribution)!

If the upstream developers spent some time to develop better interfaces, these kinds of hacks would not be needed.

gnusupport commented 3 years ago

my point is that there shouldn't be some package with first class status, like icomplete and ido,

Let me say again that it is misconception. GNU Emacs is software itself and people are free to contribute to it.

If for example author of anything or helm would organize people to contribute it directly to Emacs it would most probably be there and receive way more usage in public.

GNU Emacs is part of GNU system. For this reason intention is to protect the software by using GNU GPL.

Why the FSF gets copyright assignments from contributors https://www.gnu.org/licenses/why-assign.html

ido and icomplete are part of GNU Emacs.

ido is deprecated in favor for icomplete which is being developed.

ivy is great and is part of GNU ELPA, it could as well soon become part of Emacs.

When considering if some package has first class status, of course that built-in packages do have "first class" status, only that connotation isn't quite right.

Everybody is welcome to contribute to GNU Emacs. So that is why I asked here to contribute Selectrum to GNU Emacs.

Now you will say "No, I do not want" and then say how others have first class status with that incorrect connotation.

Well those other packages are part of GNU Emacs as somebody contributes directly to Emacs. You can do it too.

Yeah, this gets a big +1 from me. Special cases in Emacs core for third-party packages is one of the bigger ecosystem problems.

We try to avoid using "ecosystem" for free software as it implies absence of ethical judgment: https://www.gnu.org/philosophy/words-to-avoid.html#Ecosystem

It seems like within Emacs core, there is no concept of modularity or separation of concerns: if a package is supported in Emacs core, it's just kind of a part of everything, instead of being a separate part that could be included or excluded freely.

I do understand your point, and I do not see that so.

Some packages are simply part of GNU Emacs and some are not part of GNU Emacs. When we say "GNU Emacs" then we also speak of all those packages included with it, as it is GNU Emacs.

If you wish to exclude such package it is possible if you build it from sources. You may also build "minimal Emacs" from sources with ./configure --without-all as it omit almost all features and build small executable with minimal dependencies. I do it often on remote servers where I need simple editing.

You are free and welcome to participate in discussions on Emacs development mailing list:

https://lists.gnu.org/mailman/listinfo/emacs-devel

and you are free to express your views directly to developers.

Ido and Icomplete are indeed some of the worst offenders.

That is why I have proposed to Selectrum to become possibly part of GNU Emacs. Why not, if it offers good completion feature?

Isearch has a lot of random hooks throughout core, and perhaps the most egregious case is ElDoc, which has extensive explicit support for Company-specific features despite Company not even being a part of Emacs core (see elisp-mode.el.gz in the distribution)!

If the upstream developers spent some time to develop better interfaces, these kinds of hacks would not be needed.

To better understand how much time developers really spend on maintaining Emacs I suggest that you subscribe to emacs-devel and bug-gnu-emacs mailing list: https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs

as help is needed and wanted.