[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test Alternative initialize scheme

From: Nikolay Kudryavtsev
Subject: Re: Test Alternative initialize scheme
Date: Mon, 9 Apr 2018 20:42:13 +0300
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

So this is obviously not the problem, so can
you describe it again or provide an example?
I was not talking about the relationship dependence, but of coexistence. For example there's Evil, which is a package that provides Vi keyboard layout. It works fine by itself. Then there's Ivy which is a minibuffer completion interface. Ivy by default uses vanilla Emacs key bindings. Spacemacs provides some improvement in its layer that allows using Ivy with Evil. Now the question is - who's area of responsibility it is to provide that? Emacs upstream developers? Of course not. Nor should we expect developers of Evil to care about providing configuration for Ivy, or Ivy developers providing configuration for Evil. So there's a space for a third party(the first being Emacs developers and the second - package developers). The problem is how to enable those third party contributions, while taking some measures to inhibit unnecessary fragmentation. And I think it is to be expected that good solutions to this end may not be feasible.

One solution would be providing a repository for such configurations snippets and infrastructure for pulling them. And then the main dev team can ideally mark some of them obsolete or let's say broken. This of course is a mammoth task. Actually not so long ago somebody released a basic implementation of such system:

I haven't tried it myself yet, and personally I'm not a fan of org-based configs, but I have to admit that it's trying to solve the problem we're currently discussing.

Best Regards,
Nikolay Kudryavtsev

reply via email to

[Prev in Thread] Current Thread [Next in Thread]