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

Bug#966504: marked as done (emacs-ivy: should suggest not recommend elpa-smex)

Your message dated Sun, 02 Aug 2020 15:50:36 -0700
with message-id <878sewy85f.fsf@iris.silentflame.com>
and subject line Re: Bug#966504: emacs-ivy: should suggest not recommend elpa-smex
has caused the Debian Bug report #966504,
regarding emacs-ivy: should suggest not recommend elpa-smex
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
966504: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966504
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: emacs-ivy
Version: 0.13.0-1

Hello,

On Fri 24 Jul 2020 at 11:49PM GMT, Debian FTP Masters wrote:

> Changes:
>  emacs-ivy (0.13.0-1) unstable; urgency=medium
>  .
>    [...]
>    * Add elpa-smex to elpa-counsel's Recommends.  The way it presents one's
>      recently and most frequently used commands at the top of the
>      candidates list is a wonderful productivity-enhancing feature.  See
>      the docs to learn how to use Counsel to enable this for the M-x
>      interface.

Based on your description here, should probably be Suggests: not
Recommends:, given that Recommends: is for packages where it would be
highly unusual not to use ivy with them.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- 
Hello,

On Sat 01 Aug 2020 at 01:58PM -04, Nicholas D Steeves wrote:

> Elpa-counsel is an "everything and the kitchen sink" type package; it
> exists specifically to add a bundle of productivity-enhancing
> functionality to Ivy, and it's unlikely that any one user would use more
> than ~30% of it.  By far, Counsel's most useful feature is its
> Smex-to-Ivy integration via counsel-M-x, and Smex is automatically
> enabled for counsel-M-x when it is found.  Without it, counsel-M-x
> offers negligible advantages to the built-in `execute-extended-command`.
> Counsel-M-x is also the only function that is useful to the majority of
> Counsel users; however, the user must opt-in by rebinding "M-x" to
> `counsel-M-x`.  This fact is documented upstream and in Debian-provided
> docs.

Okay, looks like I misunderstood.  Specifically: almost no-one would
want to bother with elpa-counsel unless they were going to use its
features which enhance M-x, but without elpa-smex elpa-counsel barely
enhances M-x, and thus almost no-one would want to bother with
elpa-counsel without elpa-smex, so Recommends is correct.

Closing the bug.

> While I agree that dependency bloat should be avoided, I do not believe
> that this is an example of such bloat, and I'm sad that by now you don't
> trust me to make carefully reasoned decisions.

I'm sorry that my opening this bug inadvertedly suggested to you that I
don't trust your decision-making as a package maintainer.  I do trust
your decision-making as a package maintainer.  I was just responding to
what you wrote in the changelog, which does not mention how enhanced M-x
is a fundamental feature of elpa-counsel.

Perhaps I could have predicted this and written my bug report in a way
less likely to suggest anything about your abilities, so please accept
my apologies for that.

By the way, I'm not really motivated here by concerns about installation
size, but just by a general desire for the metadata published in our
archive to be correct.

> On a related topic, do you think that users would be better served by
> documenting this feature in elpa-counsel's long description, or by
> leaving it as something to be discovered in /usr/share/docs?

An interesting question.  Probably best served by some sort of quick
start guide in upstream docs?  Hard for me to say, to be honest, as I
don't use smex or ivy or counsel.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: