From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [ELPA] New package: transient Date: Sun, 3 May 2020 17:41:27 -0700 (PDT) Message-ID: <95475ccc-3239-481e-ad52-f0cf7293f91e@default> References: <87368npxw4.fsf@bernoul.li> <87ftcnxu5m.fsf@bernoul.li> <83y2qezlpd.fsf@gnu.org> <83tv12zjx1.fsf@gnu.org> <20200429101755.GF24737@tuxteam.de> <838sicw4do.fsf@gnu.org> <83zhaqu89z.fsf@gnu.org> <83sggiu2p9.fsf@gnu.org> <83r1w2s9wi.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="28906"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, Eli Zaretskii , Richard Stallman , Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 04 02:42:26 2020 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 1jVPBh-0007Qm-GT for ged-emacs-devel@m.gmane-mx.org; Mon, 04 May 2020 02:42:25 +0200 Original-Received: from localhost ([::1]:58328 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVPBg-00079H-DR for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 20:42:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42828) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVPAx-0006WU-3N for emacs-devel@gnu.org; Sun, 03 May 2020 20:41:39 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:59760) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVPAv-0006JO-Pg; Sun, 03 May 2020 20:41:38 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0440ddmZ123103; Mon, 4 May 2020 00:41:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=h9G+DtV9p4VAf+Esqs0uWyJUkJjnfwq9btnjQEqstrc=; b=sLmbBeJ7zpfR5q8f51trOLutfeYHW/GLxPyIpkbQtFFTikpbeKTbBRcBgGTS2Rq3ZdJJ ytI60CaTIV9DkPI2yborqcdzuiUlRu93ig1QUIbhC3FslMMG+GTjRm3SA8NzYHMSTD/S /oGYUaIl2h0l/9QkPn1ubPag/F3fwki8ASxP9Tjv2h0SQGAZ/pUdl+4FqCASX69Mb+LZ Bz2ytFFHOucqTKooUOt3s6C5htJb/ayV+qX4NGvkC1e/cFrQRkkm29uKkzEPkLZ9Rs12 4DpXDHB/WcnzRcV4IyRplaHhznvR75JaJB+dsxuBDbckFPCNjcYmhWIqBIpZIBN7CrJl Pg== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 30s1gmv3sw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 04 May 2020 00:41:34 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0440fXGV177704; Mon, 4 May 2020 00:41:33 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 30t1r0ut4y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 04 May 2020 00:41:33 +0000 Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0440fSCe025702; Mon, 4 May 2020 00:41:28 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9610 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005040004 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9610 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 mlxscore=0 spamscore=0 clxscore=1015 priorityscore=1501 bulkscore=0 phishscore=0 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005040003 Received-SPF: pass client-ip=156.151.31.85; envelope-from=drew.adams@oracle.com; helo=userp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/03 20:41:35 X-ACL-Warn: Detected OS = Linux 3.x [generic] [fuzzy] 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, DKIMWL_WL_HIGH=0.001, 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_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:248754 Archived-At: > > That's the rub/misunderstanding, I think. That > > namespaces are used does not imply that naming > > need be based on object type. >=20 > The propositions here aren't to group based on *types*. > Please stop those strawman arguments, again. Please stop claiming that I'm making strawman arguments. That's certainly not my intention. The idea that functions (many, some, whatever) should be prefixed by the name of a particular kind of thing - whether file-name, string, regexp,... is what I'm talking about, and I've understood that to be what at least some others have been talking about (proposing). That's different from the general idea of grouping. And it's different from the general idea of using a name prefix (of arbitrary nature: thing-kind or not). And it's different from the idea of using a library prefix - which Emacs already has and uses. (Existing library prefixes, especially 3rd-party, can be all over the map, from an author's initials to who-knows-what.) Now you say that it's not about grouping and prefixing functions that are related to the same kind of thing. OK. In that case, yes, I've misunderstood. Not a straw man, but a wrong idea of what's been suggested. > E.g. the `re-` renaming is not about any rind of "regular > expression type". They're based on the same notions of namespacing > used in modules/packages/younameit, which is also the namespacing used in > Elisp packages, as a matter of fact, so it's really not a concept > foreign to Elisp. If all you've meant is a library prefix then there's nothing new. Except perhaps if you intend to move existing functions around and put all those you want to change into libraries, renamed with prefixes. I certainly didn't understand that as what was being suggested. If that's what you meant then is it your intention that each such library would group only functions for a particular kind of thing? E.g. buffer-related functions with prefix `buffer-' or `buf-' (e.g.) in their own library, and so on for other kinds of thing? Or does it really have nothing to do with grouping by thing-kind (and prefixing accordingly)? I haven't seen a clear proposal, so perhaps you'll forgive me for trying to guess what you and others have meant, and guessing wrong (misunderstanding). I've been under the impression that there's been a suggestion, by some at least, to use a thing name as the prefix. And that can entail, for example, moving it to the front from the middle of an existing name - e.g. rename `multibyte-string-p` to `string-multibyte-p`, to put `string' (the thing tested) first. And I thought two of the arguments for that were (1) consistency and (2) aid with completion (e.g. many of the regexp functions with prefix `re-', many of the string-related functions with prefix `string-') - the latter point being that it can help you find and access the functions concerned with a given type/kind of thing. If it's about a library prefix, is your idea to have a library for regexp stuff, a library for string stuff, etc., each with such a library prefix? Frankly, what's proposed seems to be getting less clear. But maybe that's just me having difficulty following. You've said, regarding the string case, that it's not about prefixing "string-manipulation" functions, but it's been said to be about prefixing=20 "string-related APIs". Similarly, for regexps, I thought. I think I've made _my_ arguments clearly enough, so perhaps I can stop here. If they don't conflict with what you want to do, great. If they do, that's OK too. At this point I don't really know what you want. I guess I was mistaken before, in thinking I knew. In any case, believe me that I'm not trying to misrepresent whatever it is that you're proposing, as some straw-man argument to attack. I thought I was addressing what was being proposed.