Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip K.]

Gregory Heytings <gregory@heytings.org> writes:

>> Well none of these should so it, with the possible exception of
>> activating, that I'll mention again below. But I still think that
>> the distinction is important, if only because it is real. I recently 
>> realized there would be another problem with this approach, as you
>> also mentioned that global modes should activate themselves on
>> installation, specifically naming Ivy, the completing-read
>> framework. But what if someone decides to install Helm? Will these
>> two modes now interfere, possibly breaking everything, or is it
>> Helm's responsibility to deactivate Ivy. If so, does every
>> completion framework have to know about every other one?
>
> That question and the problems you raise are orthogonal to the problem
> at hand.  I did not say that the distinction isn't important in
> general, only that it isn't relevant for the problem that the proposal
> attempts to solve.
>
> I have no opinion about whether it is better for packages to install
> global bindings at installation time, at loading time or at activation 
> time.  At first sight it seems to me that all three could make sense,
> depending on the package.

I do think that the problems are relevant, because they show that
activation at install- or load-time are bad style. The only real choice
is activation-time, but that won't work for examples like Magit, since
they are not activated using modes. I'm not sure how I'd feel about a
magit-global-mode...

The only real solution that I see is something along the lines of what I
recommended: Packages suggest customizations, and package-install may
either ignore, ask for confirmation or accept them by default, if there
are no problems with what is suggested (eg. collisions). This avoids all
of the issues I have mentioned, will make it easier for newcomers
without annoying existing users, at minimal expense to package
maintainers, while providing information that can even be used by other
third-party packages (e.g. use-package can use the suggestions to
automatically build a configuration block).

-- 
        Philip K.

signature.asc
Description: PGP signature