-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Could you consider your package to be included in GNU ELPA? #225
Comments
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. |
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. |
* Radon Rosborough <notifications@github.com> [2020-11-07 07:17]:
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.
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.
|
* Radon Rosborough <notifications@github.com> [2020-11-07 07:16]:
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.
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.
|
Sounds good! I understand your point of view, it definitely is nice when packages are more easily accessible. |
@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 |
* Daniel Mendler <notifications@github.com> [2020-11-08 17:26]:
@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 would 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
rest. 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.
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.
|
@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. |
* Daniel Mendler <notifications@github.com> [2020-11-08 19:07]:
@gnusupport I am not involved with this project. In case you
misunderstood this. I am as external to this project as you.
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.
|
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! |
* Daniel Mendler <notifications@github.com> [2020-11-08 21:26]:
> 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!
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.
|
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 If the upstream developers spent some time to develop better interfaces, these kinds of hacks would not be needed. |
* Radon Rosborough <notifications@github.com> [2020-11-15 20:26]:
> 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.
|
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.
The text was updated successfully, but these errors were encountered: