Re: [ELPA] Proposal to add consult-dir to ELPA

[Philip Kaludercic <philipk@posteo.net>]

Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:

> Thanks for the review, I'll apply your suggestions and get back to you
> when I can.
>
>>> I have found it to be a surprisingly versatile tool, and many users have
>>> told me over the years that it solves a problem they didn't realize they
>>> had.
>>
>> What is not clear to me is why this is not a part of Consult, if it is
>> as useful as you say.  Have you discussed this with Daniel?  In any
>> case, it would be useful to explain that somewhere.
>
> This discussion was had in
> https://github.com/minad/consult/issues/373#issuecomment-889841426.
>
> The conclusion was that it would be better to have this be a separate
> package.  Here is the relevant part of the exchange:
>
>> DANIEL: ...I am not sure. And since Omar still has his bookmark
>> directory jumper, there is probably a need for such a feature. Maybe
>> one should also reconsider adding some new commands to Consult itself
>> which fill the gap. Generally I am hesitant to stuff much more
>> functionality into Consult itself, but a directory selection command
>> does not sound unreasonable.
>>
>> ME: If you're interested in adding this to Consult, I can submit a
>> PR. I'm okay with it living in a separate package though.
>>
>> DANIEL: Currently not, since I don't have a clear picture of what I
>> want. But if it turns out that we find something small and generic I
>> would be happy to add it. But adding multiple new sources, many commands
>> etc, does not seem to me like a good idea at this point. I'd rather
>> modularize the ecosystem more. Right now Consult is already pretty much
>> a kitchen sink, but my general guideline is to maintain mostly reusable
>> components here. For example consult-org-heading is a generic Org
>> jumper, and you can glue it together with other commands or with Embark
>> in order to get richer actions on the headings. Another example is the
>> recently added consult-line-multi, which allows you to specify a query
>> argument to restrict the set of buffers. This way I avoid having to add
>> more special consult-line-all-buffers-of-this-and-that-type style
>> commands.

This conversation is from 2021, and you are saying this is still the
state of the discussion?  Just to be clear, it doesn't matter much
either way, I just want to make sure there is no latent interest in
merging the two packages.

>>> I have signed the copyright papers, and there are no contributions to
>>> the project from users over 3-4 lines in length.  Consult-dir's only
>>> external dependency (Consult) is in ELPA.
>>
>> 1+ (though I have suggested to depend on project so as to lower the
>> dependency on Emacs).
>
> Why is adding another dependency a good idea? Isn't Emacs guaranteed to
> ship a supported version of `package.el'?

Yes, but IIRC the functionality you were using was not available in
Emacs 26, but you could install a newer version from ELPA with the
missing functionality.

> Karthik

-- 
	Philip Kaludercic on siskin