From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: listen Date: Mon, 26 Feb 2024 08:09:31 +0000 Message-ID: <87wmqr7ikk.fsf@posteo.net> References: <51bcca65-2690-4f23-98bd-d929e63d7f94@alphapapa.net> <87il2cdb17.fsf@posteo.net> <6e496679-63f0-4a30-aa6a-8402ff96a6a1@alphapapa.net> <87zfvoac8r.fsf@posteo.net> <49be5d31-043d-4776-8284-b8c4a611ec5f@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1342"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Adam Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 26 09:10:56 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1reW4d-00007E-AH for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Feb 2024 09:10:55 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1reW3R-0000AS-PQ; Mon, 26 Feb 2024 03:09:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1reW3P-0008VH-9n for emacs-devel@gnu.org; Mon, 26 Feb 2024 03:09:39 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1reW3M-0002Gi-NM for emacs-devel@gnu.org; Mon, 26 Feb 2024 03:09:39 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 7043B240101 for ; Mon, 26 Feb 2024 09:09:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1708934973; bh=XmxjibHaOJZNKLdMIPSfiJ8SqhJLrmAhWTcZBAKHUDY=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=Lf+FTXWAyIkYc1uKlbKznfPhZ3nDz3EP3povzbEsyI53YcD63GnMo8vnfIh1zLsi4 uDf4mcPubOvqgO9lxP5jeZ8bv7w3wOJhmDMArRwcsUZiKtJqowyGAk2X1zZ+icy1oc 01Pc0B0G/QOxzMF21PsEXQbpUn73cAgbVNUxH/hAhKcAaCPDLe1SgqeoGjpQQPmFXa /nQuvx7ubKyAjwemxVv0kYAJHXH5uxK/LqAdPe6mUfJnN2qmGWUMWwPyw/2wvS1Jwi 7ZWCcpsQMDs1rPvw40S7mnn+UHw5DJeMYFNmAo5mjHPlWBOCZubgc3ORKh70yrPywn ETqZxbgXmjPjQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TjtZ44jxKz9rxR; Mon, 26 Feb 2024 09:09:32 +0100 (CET) In-Reply-To: <49be5d31-043d-4776-8284-b8c4a611ec5f@alphapapa.net> (Adam Porter's message of "Sun, 25 Feb 2024 22:15:44 -0600") OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316548 Archived-At: Adam Porter writes: >> There were a few other places where you did (delq nil (mapcar ...)) that >> might be replaced by this pattern. > > I confess that I've hardly ever used MAPCAN in any of my code--still, > I'm not sure how that would help to avoid that pattern. For example: > > (let ((a '(1 nil 2 nil 3)) > (b '(4 nil 5 nil 6))) > (mapcan #'identity (list a b))) > > ;; (1 nil 2 nil 3 4 nil 5 nil 6) > > But I'm probably missing something. 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. >> Not really, if you don't care about compiler warnings. It just seems >> like the kind of things that could cause problems at some later time, >> when definitions are moved around. > > I do care about compiler warnings--I wrote makem.sh to catch such > warnings in my projects before they reach users--but in this case, > that code's not going anywhere, because it's already with > bookmark-related code. Feel free to do as you like (none of this is barring inclusion, if that wasn't clear), that was just a suggestion. >> 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! >>>> @@ -328,7 +328,7 @@ PROMPT is passed to `format-prompt', which see." >>>> n) >>>> (when current-track >>>> (cl-callf2 delete current-track tracks)) >>>> - (setf n (length tracks)) >>>> + (setf n (length tracks)) ;why the variable? >>> >>> Because the value is used elsewhere in the function. Am I missing >>> something? (Anyway, as noted in the source, I did not write that >>> function.) >> Then I missed something, because I just saw the variable being >> declared >> in the let-head, set here and used once later. > > It's used in two places, and it would be undesirable to recalculate > the list's length every time through the loop. I see it now, sorry. >>>> On the topic of the readme/manual, wouldn't it be better to have a >>>> separate README file? Then again, the manual is pretty short, and I >>>> don't know if it is worth having it in the first place... >>> >>> As you said, this readme is currently trivial. Were it larger, >>> however--well, I have other packages with much larger readmes that are >>> also converted to manuals. There would not be much gained by >>> separating into files. >> I don't think that is a good practice. A README for when you have >> fetched the sources and want to figure out what is what, a manual for >> when you have already installed a package and a package description for >> when you are previewing a package using C-h P are three different >> things. One shouldn't cover all of it with the same file if you ask me, >> since they all have different audiences with different levels of >> interest. > > I don't know about that. Especially for small packages with trivial > documentation. Maintaining documentation and commentaries, keeping > them reasonably in sync, etc. is enough work without having them split > into multiple files. Having a README.org which is viewable at the > package's repo also generate the manual is a relief to me. 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. >>>> 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. >>>> 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? -- Philip Kaludercic on peregrine