Hi Sean! Sean Whitton <spwhitton@spwhitton.name> writes: > On Sat 01 Aug 2020 at 01:58PM -04, Nicholas D Steeves wrote: > [snip my rationale] > > 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. > Thank you :-) >> 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. Thank you, I'm relieved to hear that that all the work since you initially mentored me for muse-el was not in vain :-) > 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. > Fair point. By the way, I concede that choosing not to censure the human element of my changelog entry makes it appear that the decision was possibly an "emotional" rather than "rational" one. Given the prevalence of negative and degrading changelog entries (eg: "useless", "good for nothing", "garbage", etc) there is precedent for rational+emotional in Debian culture, and I think we can agree that rational+positive_emotion entries are more congruent with the project's ideals. > 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. > Thank you for this, always appreciated! :-) P.S. a number of our team packages are not yet Policy ≥ 4.1.3 compliant (§7.8 "Built-Using"). >> 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? Confirmed; Some info is already there "Ivy re-uses [automatically] the following packages if they are installed: avy, amx or smex, flx, and wgrep", plus documentation on how to activate counsel-M-x but it doesn't detail what is activated where. >> eg: Is perfect documentation 100% comprehensive, or should it leave >> room for the joy of discovery? I understand this is a qualitative and philosophical thing, and probably outside the scope of Policy, but if I interpret what you've written correctly, would it be this: Perfect documentation would be 100% comprehensive, but most users won't read it, and were they to spend the time reading it this would count as discovery? ...albeit probably not joyful, because I've never heard anyone describe the process of reading docs as such (except An Introduction to Programming in Emacs LISP. That one is a joy!) Otherwise, the quick-start guide might ideally omit certain details not only in the interests of brevity, but also to allow for the joy of discovery? > Hard for me to say, to be honest, as I don't use smex or ivy or > counsel. > On this topic, would you like me to adopt smex? I've noticed that it's your package and is in need of some work. If so, please grant me DM for it. Regards, Nicholas
Attachment:
signature.asc
Description: PGP signature