From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Help sought understanding shorthands wrt modules/packages Date: Mon, 14 Nov 2022 03:03:22 +0200 Message-ID: <93db8859-71af-b939-8ad5-b2850b914947@yandex.ru> References: <25a8a3a6-81c8-3fbc-434d-fb1b24ae1d62@gmail.com> <83cza48lxe.fsf@gnu.org> <87cza0ihb7.fsf@gmx.de> <87o7td7qfu.fsf@gmail.com> <87tu345vod.fsf@gmail.com> <73c09027-b62f-4a0c-cad9-1dafee664f27@yandex.ru> <7838e54a-a427-d01c-6e57-a0ce70ef9352@yandex.ru> <87fseom2q3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6594"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cc: Richard Stallman , emacs-devel To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 14 02:04: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 1ouNtt-0001Uz-NW for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Nov 2022 02:04:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouNtB-0005Jp-LR; Sun, 13 Nov 2022 20:03:53 -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 1ouNt9-0005JS-Ms for emacs-devel@gnu.org; Sun, 13 Nov 2022 20:03:51 -0500 Original-Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ouNt7-00023Y-HB; Sun, 13 Nov 2022 20:03:51 -0500 Original-Received: by mail-wr1-x435.google.com with SMTP id z14so15015625wrn.7; Sun, 13 Nov 2022 17:03:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=uZ721+zKnc1osEYMRNvNiwYo/cH3JNCBvolLSCS/S70=; b=II2ppTFp6qt4gSL++5c4F/2ZeCI6Z2vWHDNNnR7QIJogtg2fzsH1I+MEn5Pwp2r8/c ekJt69fUcWq7xcWai7H22/DXQCXutrzb6zv85EQ7IBM1xBXzhl7dRoWxXjIlVJOkkoyM OQUvSkw75fFRB7i55ib6ZvAlRqaIipjt/E6qdBvm3gCACGD5WHWnv39sc10kIaL6qjLc nvnmXDnON9YXracU7AIo7pZBaxJqWTyGEfX5v0vAfBm++Zxg6cRH/DSMfvmByPax74ok Q7VB/Ja8DLBU6SYEPqEr+CraykBBz//yoqgq1LqRqNJ+rL/T/dyGSA47okOg7J6L1j1j AK/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uZ721+zKnc1osEYMRNvNiwYo/cH3JNCBvolLSCS/S70=; b=gpbB18n4ZB2JXOaoixOQpgU/N3jGvW+uQJ7D3anXtEJscEpmle71GZuSKD/89bT3uW C/hZnUt+bgjn8UdxNBcazAwLjERO+pVcEoo0hUgmCI2SkgA+qfZd2dxcPfXuKMb+vprP QwJtdoh+/vcX5eNBxbWRqTn0sijedK1dU7HEjr4FwKhUBsyGDgwlhTNE1YxNYigUNd2L 2wUmqK/sz4s0GzT1bDI3oqwye7BA5/pEPMEbN9VGhgGUB7uwdevsLERE6J7L8d2+1Ch1 i3cu1SmxwrjE6vZbnC5GLfy+ZK3fE7hrwTovgc3fU/bVEvcnmGNR1PtbVDf7eyQZuSJD UXqg== X-Gm-Message-State: ANoB5plUH+26YLaSG87G4fEKt8lIIlIdDTcawGX0WK7lpbnvKweg7HN1 Rr7r6qSuodEqkzcvRLmAs1A= X-Google-Smtp-Source: AA0mqf5VEqN88yqSqkntija56NV+yl5HWS4XFy7za5sgQQ/RgndpBq+UaJancXYiImCBr80jPhaJVQ== X-Received: by 2002:adf:f80c:0:b0:236:5c7e:4b92 with SMTP id s12-20020adff80c000000b002365c7e4b92mr6415292wrp.72.1668387807912; Sun, 13 Nov 2022 17:03:27 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id bd10-20020a05600c1f0a00b003cfbe1da539sm11177147wmb.36.2022.11.13.17.03.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Nov 2022 17:03:26 -0800 (PST) Content-Language: en-US In-Reply-To: <87fseom2q3.fsf@gmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::435; envelope-from=raaahh@gmail.com; helo=mail-wr1-x435.google.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:299766 Archived-At: On 12.11.2022 20:45, João Távora wrote: > I've tried to explain my original plan again. It would seem you have > read it: do you understand it? Do you see anything technically wrong > with it? If you don't then maybe you could help convince others that > it's a viable plan It sounds workable, but I'm not convinced myself that this approach is going to be attractive enough for third-party package authors. As well as for the author of s.el. And if I don't see it as attractive, what hope would I have of promoting it? First: would the author want to rename it to magnars-string or strings? I don't know, both seem more generic than 's.el' which is pretty well-known by now. And if you look at some discussions, he doesn't want to break compatibility with older Emacs without very good reason. Second: why is the existence of s.el a problem? Does somebody else want to use this name? I could understand it if we wanted to introduce such namespace in the core, but as some related discussion has shown, the maintainers don't value this kind of naming scheme (consistent prefixed naming and very short names), so in the end what? It will sit unused? The main value of s.el IIUC is in its superficial qualities: the easy-to-grasp names, the searchable README.md which lists all the methods, and the naming of functions which is friendlier to Clojure users. If we take away the naming, what's left is perhaps a dozen of added convenience functions. >> Otherwise, we've just acquired some extra complexity in the reader, >> xref and elisp completion code, while the anticipated benefits are >> very slow to materialize. > > I'm not sure the complexity is that much (it was a long time ago, but I > believe it was reasonably low). But you're right, the benefits of > shorthands so far are just programmer convenience for libraries outside > of Emacs. I've enjoyed using them, and I would guess a small number of > programmers are also taking advantage of them them in some side > projects, judging from a quick GitHub code search. My own search on GitHub has yielded nothing so far. >> Half a year has passed now since Emacs 28.1's release, and even longer >> than that since the "shorthands" have been installed on master, and I >> don't see a single mention of them on s.el's issue tracker. >> >> Ditto for dash.el and f.el. > > For the record, I think you're completely right. But hey, this is > Emacs, it moves slowly. Again, if you understand the plan I put forth > and you think it's viable, then speak up and let's get things moving. Third-party packages also usually want to keep compatibility with several older Emacs versions. So perhaps we can see some movement when the year 2028 rolls over, and I will be proven wrong.