From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.devel Subject: Re: plz -> curl? Date: Sat, 21 May 2022 12:29:06 +0200 Message-ID: <875ylzkwlp.fsf@bernoul.li> References: <874k1vzyom.fsf@posteo.net> <104ffa6b-12ae-53df-e289-aba7d7200654@alphapapa.net> <87o7zxnfsg.fsf@yahoo.com> <87pmkcmv2t.fsf@gnus.org> <87wnekmpsb.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12281"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , Richard Stallman , Adam Porter , philipk@posteo.net, mardani29@yahoo.es, emacs-devel@gnu.org To: Stefan Monnier , Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 21 12:31:38 2022 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 1nsMOY-000318-3F for ged-emacs-devel@m.gmane-mx.org; Sat, 21 May 2022 12:31:38 +0200 Original-Received: from localhost ([::1]:55204 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nsMOW-0007Gd-EP for ged-emacs-devel@m.gmane-mx.org; Sat, 21 May 2022 06:31:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nsMMB-0006Qk-Sh for emacs-devel@gnu.org; Sat, 21 May 2022 06:29:11 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:46018) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nsMMA-0002xm-6I; Sat, 21 May 2022 06:29:11 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 28299165D1; Sat, 21 May 2022 12:29:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from:received :received; s=sel2011a; t=1653128946; bh=XJy9C72kG4RBYD6Grl9/FM0k eMKjMJ6wj0zYqJeJpxw=; b=vYr2Cz02qvHXqCDZlIxwNEiwF4JEm5C0kBtWjwKK tn6CbJUwwzRttRJI4/a1eQg98mIRmfrVchXr+Z/wgtiajRrZW+H6YO6oKILfadDw ZvDZ/F6NyDGV0krbg57u2B+7gUOr5bPkqtTidbm8AFg6iQ5H9YPPpAo3L+yOCpQG yng= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id A9f9ovT6n_nf; Sat, 21 May 2022 12:29:06 +0200 (CEST) Original-Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id E0E3816595; Sat, 21 May 2022 12:29:06 +0200 (CEST) In-Reply-To: Received-SPF: none client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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" Xref: news.gmane.io gmane.emacs.devel:290045 Archived-At: Stefan Monnier writes: > It's always easy to retrospectively decide which package should have > which name (after the dust has settled and one of the contenders for > a given name has accrued a decisive advantage), but backward > compatibility as well as the need to choose a name before the dust has > settled (which can take a very long time) mean that non-obvious names > are here to stay. Using cute names for unproven third-party packages also has the advantage that the boring authorities name is still available when the Emacs developers decide to implement "official" support for the same thing. And if that is done by adopting an existing solution, then that is the best time to rename that package and all its symbols. Downstreams would still be inconvenienced by such a change but they are likely to be much more forgiving when it happens at that time. After all they get something out of it too; the package they rely on is now the official solution and less likely to break in backward incompatible ways *going forward*. > Instead we need to work on improving discoverability based on other > things than merely the package name. Like finder.el? ;D > ;; These are supposed to correspond to top-level customization groups, > ;; says rms. > (defvar finder-known-keywords '( 36 elements)) Maybe we should allow classifying packages into more than three dozen groups?