Re: [ELPA] New package: listen

[Philip Kaludercic <philipk@posteo.net>]

Adam Porter <adam@alphapapa.net> writes:

> On 2/26/24 02:09, Philip Kaludercic wrote:
>
>> The pattern I usually use is something like this:
>> (mapcan
>>   (lambda (n)
>>     (if (> n 0) (list n) nil))
>>   '(1 -2 5 0 -10 10))
>> ;;=> (1 5 10)
>> The idea is that when using `mapcan', you provide the cons-cells of
>> the
>> resulting list, instead of having `mapcar' generate them for you and
>> then immediately discard them via `delq'.
>> There should be a seq method for this pattern imo.
>
> Interesting, thanks.  It looks like the performance of that technique
> is slightly better than (delq nil (mapcar ...)), but if performance is
> a concern, then it looks like one should use a loop:
>
> (benchmark-run-compiled 1000000
>   (mapcan
>    (lambda (n)
>      (if (> n 0) (list n) nil))
>    '(1 -2 5 0 -10 10)))
> ;; (0.21211651699999998 0 0.0)
>
> (benchmark-run-compiled 1000000
>   (delq nil
>         (mapcar
>          (lambda (n)
>            (when (> n 0)
>              n))
>          '(1 -2 5 0 -10 10))))
> ;; (0.21806460800000002 0 0.0)
>
> (benchmark-run-compiled 1000000
>   (cl-loop for n in '(1 -2 5 0 -10 10)
>            when (> n 0)
>            collect n))
> ;; (0.052528039 0 0.0)

True, invoking the lambda expression is probably the most expensive
part, but testing this on a 6-element list with a check that is
basically an opcode, restricts the universality of the claim we are
trying to make.

>> My point is that there shouldn't be an overlap.  I think a README
>> shouldn't contain too much detail, but serve as a signpost (suitable
>> both for online and offline (!) reading): "This is brief summary of what
>> you have found, the source code is hosted here, you can find the
>> documentation there, my contact information somewhere else, etc.", while
>> the package description gives a high level overview that doesn't have to
>> updated unless the entire idea of the package changes, while the
>> documentation goes into the nitty-gritty details.
>
> I understand what you're saying, but I think there is often value in
> having all of those categories of information in a single file,
> especially for smaller packages.  It's similar to the experience of
> being able to quickly scan through a man page compared to having to
> page through an Info manual.

I am not sure how the last point related to what you are saying, because
that sounds to me like an argument for not using the manual as the
package description.  And you already have a shorter package description
in the main file in your commentary section.  (It is possible to
instruct ELPA to use this for C-h P, instead of rendering the manual).

>>>>>> Also, your README includes this line
>>>>>>      :vc (:fetcher github :repo "alphapapa/listen.el")
>>>>>> which is malformed.
>>>>>
>>>>> I just tested that, and it works for me.
>>>> On Emacs 30?  That is not the code we merged...
>>>
>>> No, I'm using Emacs 29 with `vc-use-package'.  Its documentation seems
>>> to suggest that it uses the same format as that merged into Emacs 30,
>>> since it says that its features were merged into Emacs 30.
>>>
>>> Maybe `vc-use-package's documentation should be updated to reflect this?
>> Do you mean this: https://github.com/slotThe/vc-use-package?  I have
>> no
>> involvement with that project, but I don't see where they mention the
>> "fetcher" notation you mention.
>
> I see it in its readme under "Usage".

Oh, right.  Then I guess that should be noted somewhere to avoid
confusion.

>>>>>> What you want is
>>>>>>      :vc (:url "https://github.com/alphapapa/listen.el")
>>>
>>> Ok, so no ".git" on the end (i.e. relying on the GitHub redirect)?
>> That doesn't matter (FWIW I didn't know either of the two was a
>> redirect).
>> 
>>> And does this mean that none of the host-specific "fetchers" are
>>> available in Emacs 30?  (Which FTR is fine with me, as the URL should
>>> be enough, I'm just curious.)
>> No, the package-vc extension for use-package uses the same package
>> specifications as package-vc?
>
> Sorry, I don't understand: "No, it doesn't mean that," or, "No, the
> fetchers are not available in Emacs 30"?

There is no ":fetcher" keyword in Emacs 30.

To rephrase my above sentence: The version of use-package in Emacs 30
has a :vc keyword, that accepts mostly the same syntax for package
specifications as `package-vc-install' does (which in turn is the same
as what elpa-admin uses).

-- 
	Philip Kaludercic on peregrine