Re: [ELPA] New package: listen

[Adam Porter]

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)

> > > Ah, the `t did confuse me momentarily, but in that case you can replace
> > > the (guard ...) with (and 't (guard ...)).
> >
> > As much as I advocate using pcase and its powerful expressions, I
> > think that would make this example harder to follow.  The pcase
> > pattern is used to test an argument, and the string test is a separate
> > concern.
>
> But consider the saved indentation!

Ok, I will.  :)

> 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.

> > > > > 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".

> > > > > 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"?