evil contrib repo #769
Comments
|
Well, isn't Spacemacs basically the one and only Evil contrib repo you'd want to go for? No, I don't use it myself, otherwise I wouldn't suggest it. As for breaking out the code, most of the integration code is really small and fixes up annoyances such as them being repeatable when they shouldn't. I don't really see the point in making users go through a backwards-incompatible change which amounts to them adding more require expressions to their code. |
|
@justbur are you proposing like a curation of unmaintained evil packages? I'm all in for that. |
I don't know what you mean. This doesn't have anything to do with spacemacs
It has already been suggested that repos that are unmaintained could be brought under this organization. I think that's a good idea. I was volunteering to add evil-ediff and evil-magit to this organization. These are stable and reasonably popular. Putting them here allows more people to look after them and also gives them more visibility. I thought eventually other evil-x packages that are popular and stable could be solicited and collected here for the same reason. evil-ediff and evil-magit are just integration packages, but are somewhat more involved (and opinionated I guess) than the stuff in evil-integration.el. So I guess the distinction is valid. |
Well, Spacemacs is a collection of configuration (known as "layers") specially made to make Evil more integrated into Emacs for Vim refugees. As there is a significant community involved in those layers, it's basically a community repo for Evil-related configuration. My conclusion from this is that if you want integration going beyond Evil's basics, either write your own, install packages or use Spacemacs. There isn't much need for Evil to expand its integration efforts if other projects do so. Hosting relevant packages at our organization however would be fine. |
|
I was only talking about the hosting part. I think it would be helpful (to
whatever extent seems reasonable) to make the integration packages
available centrally. I don't want to write configs for people, but if
creating a config for yourself can be made easier that would be a good
thing in my opinion.
…On Tue, Feb 14, 2017 at 2:58 PM Vasilij Schneidermann < ***@***.***> wrote:
I don't know what you mean. This doesn't have anything to do with spacemacs
Well, Spacemacs is a collection of configuration (known as "layers")
specially made to make Evil more integrated into Emacs for Vim refugees. As
there is a significant community involved in those layers, it's basically a
community repo for Evil-related configuration. My conclusion from this is
that if you want integration going beyond Evil's basics, either write your
own, install packages or use Spacemacs. There isn't much need for Evil to
expand its integration efforts if other projects do so. Hosting relevant
packages at our organization however would be fine.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#769 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACGyfnCsp-4IFJCNhGCSf3UChHApnRO_ks5rcgdagaJpZM4L_jYS>
.
|
Yes, many people go for install packages because, after a point, spacemacs is a hindrance to customization. And I'd like those packages to be mantained, ideally. Some packages are a must have, even used by spacemacs and are abandoned. For example, evil-surround, which I mantain now, with near zero elisp knowlege. Not a pleasant state of affairs. |
|
@TheBB thank you. I surely will try to contact @timcharper about this. It is certainly a core evil package. I mean tpope's plugin has like 4,4k stars. Using vim without vim-surround is a rare sight. You gentleman may recall that a few months ago, the Now this was happening due to a regression that I've bissected here. This error was in production for almost 4 months. So now I need to write some tests, but I've never wrote an elisp test in my life. Because of things like this, I see this curation initiative as a huge improvement in "fostering evil". We could write like a common testing framework, make sure that the curated packages don't brake in future versions of evil, etc... |
|
@TheBB thanks. I just moved them. I'll send the update request to melpa for the recipes. |
|
@justbur Do you consider this resolved? If yes, please close this issue. |
|
Yes I suppose |
@TheBB, I just got the response back from @timcharper and he is cool with moving evil-surround to the emacs-evil organisation. Here's the email exchange: Hi Filipe
Not sure why my email client decided to prematurely send. :/
Today is http://emaildebtforgiveness.me
I'd be totally willing to move the package.
Tim
On Tue, Feb 14, 2017 at 2:41 PM Filipe Silva <[email protected]> wrote:
Hi again Tim,
You may know that evil now lives in a github organisation: http://github.com/emacs-evil/evil
An idea came about recently, about curating packages of the evil ecosystem here. And your evil-surround package was mentioned.
Would you be willing to move the evil-surround package into the official evil organisation, where it could be fostered and supported by the community?
Of course we would mantain all credits and copyright notices entitled to you.
What do you think?
best regards,
ninrod,
(github.com/ninrod) |
|
Sure, I'm fine with this, but would want more approval and let someone else do the migration, like @TheBB. |
Hi, I think it would be nice to manage the various evil integration configurations in the emacs-evil organization. I saw this comment about unmaintained extensions and would like to add some of my own like evil-ediff and evil-magit to this list. I'm happy to contribute but would like others to chip in if possible.
There are existing configurations buried in evil-integration.el that I also thought could be broken out into separate files to make them more visible and more optional. I think it would also be nice to have some "official" extensions that would be easy for new people to find.
I don't have a strong opinion on how to organize things.
The text was updated successfully, but these errors were encountered: