Re: [NonGNU ELPA] New packages: Vcomplete, swsw

[Philip Kaludercic <philipk@posteo.net>]

Daniel Semyonov <daniel@dsemy.com> writes:

>>>>>> Philip Kaludercic writes:
>
>     > - You add vcomplete-embark.el, that seems to be a package in it's
>     > own right (with a dependency on embark), but with your patch this
>     > will just be bundled into the same package.  Is this intentional?
>
> Semi-intentional... now that you mention it, is it possible for two
> (related) packages to share the same git repository? If so,
> vcomplete-embark should be its own package.

It is, though not advised if not necessary (it works by excluding all
the files from package B in the specification for package A, and vice
versa).  A slightly more elegant approach is to use separate, detached
branches but at that point you effectively have two repositories anyway
(that you can associate as part of the same project on SourceHut).

> In any case, I haven't tested this integration in a while, so I think it
> would make more sense to completely exclude 'vcomplete-embark.el' for
> now (this integration broke in the past due to changes to Embark and
> Vcomplete, and might be broken in some way now as I don't currently use
> Embark).  I'll do some testing in the next few days.

In that case I'd advise just adding it to a .elpaignore so that you
don't have to change the package specification upstream.

>     > - Could the vector key syntax ([?\C-a]) be replaced with a (kbd
>     > "C-a")?  I think the general trend nowadays is towards the latter,
>     > and more people are familiar with it.
>
> Now that you mention it, since it's just an example, wouldn't it make
> more sense to use 'keymap-set' for it? (Although technically both
> packages could be used with an Emacs version that doesn't support
> 'keymap-set').

I wouldn't, as your package-dependency specification indicates that the
minimal version is 25.1, and no release of Emacs has been made with the
new keymap functions/macros.  It is easy for enthusiasts to forget that
most people are not tracking the master branch.

>     > Have you made up your mind about the name, or could you be
>     > convinced to change it to something like "window-switch" or
>     > "windswitch" (so that it sounds similar to windmove)?  Just
>     > suggestions of course, I just anticipate a discussion on this
>     > question, because the name itself is not that expressive.
>
> I wouldn't mind changing the name (I agree it's not very good), however
> I would have to change this name in quite a few places.
> OTOH, with 'list-packages' showing a brief description of each package,
> I'm not sure if I see a big benefit to changing the name.  I'll have to
> think about it.

Ok, no problem.  As I said it is just a suggestion, perhaps someone else
has a better idea that might make the change worth the effort.

>     >> PS: I initially intended to submit these packages to GNU ELPA,
>     >> but unfortunately I probably won't be able to assign copyright
>     >> any time soon. (I'm assuming it would be possible to move them to
>     >> GNU ELPA in the future?)
>
>     > It should be possible.
>
> Great!
>
> BTW, when the packages are first imported, would the latest commit be
> used, or should I bump the version (after I make all relevant changes)?

No, the last commit that bumps the version tag is always the one used.
I can push the specifications, though I will wait for a bit to see if
anyone wants to comment on anything discussed here.