Re: [elpa] main 8f4cb59: * elpa-packages (counsel, ivy, swiper): Auto-sync.

[Stefan Monnier <monnier@iro.umontreal.ca>]

> The packages ivy-avy and ivy-hydra are considered optional integrations
> with the separate packages avy and hydra, respectively, so they seem
> like the best candidates for splitting into separate packages (or
> merging with the avy and hydra packages, I think).

`ivy-hydra` seems to be "extra `ivy` functionality, using a hydra",
rather than "`ivy` support for hydras", so I don't think it belongs with
`hydra.el`.

OTOH, I think it should be included into `ivy`.  IIUC this is currently
not done because it would require adding `hydra` as a dependency to
`ivy`, but my counter argument would be that the better option is to add
to `hydra` a new *function* to replace/complement the `defhydra`
*macro*, so that `ivy-hydra.el` can be included into `ivy` (and compiled
correctly) without needing to add a dependency on `hydra`.

For `ivy-avy` I think the argument is almost the same, except I don't
see any reason why it isn't done yet (there doesn't seem to be any need
for `avy` to be around to compile correctly `ivy-avy`).

So, let's start with this: Could we merge `ivy-avy` into `ivy`?

>> Fetching tags from upstream is problematic (because we have a single
>> elpa.git repository for all packages), but we could use tags manually
>> pushed to elpa.git, yes.
> I was thinking of the latter indeed, as a more "Git-native" way of
> pointing to a release.

That'd be fine by me.

> I can't promise to implement any of these features for another few
> months though (at least not without a guilty conscience ;).

Oh, if you need an extra guilty conscience in order to get to work,
I can help, I have plenty of those here.


        Stefan