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: Imports / inclusion of s.el into Emacs Date: Sat, 2 May 2020 16:10:03 -0700 (PDT) Message-ID: References: <831ro2tqqx.fsf@gnu.org> <4a1fd3f4-df92-c756-9874-4d07b54148ac@yandex.ru> <3bd09dca-dcdc-7569-e5fb-f6b53397af9d@yandex.ru> <83bln6s5on.fsf@gnu.org> <6d43996b-65ab-0bc6-9124-156520396910@yandex.ru> 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="102767"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org, joaotavora@gmail.com, rms@gnu.org, Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 03 01:10:47 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 1jV1HS-000QfH-W1 for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 01:10:46 +0200 Original-Received: from localhost ([::1]:46450 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jV1HS-0006lM-1P for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 19:10:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58704) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jV1Gw-00068i-An for emacs-devel@gnu.org; Sat, 02 May 2020 19:10:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jV1Gv-0004XC-Jr for emacs-devel@gnu.org; Sat, 02 May 2020 19:10:13 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:49814) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jV1Gt-0004Pi-AS; Sat, 02 May 2020 19:10:11 -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 042N7Xd7104878; Sat, 2 May 2020 23:10:06 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=GdRhasDX93QD0MzP5Wexy2Tb+NUbWPBWR14un9UTCsM=; b=bxBjJcNZa4+kzZA0kSS+T8NGnR23tLbx6SaIBn1MRhADvl5SKuXc9386LNmfK1KpCO+A 5S6jnP/s4XTpUYfmAIDmDC+owmmETPMSqshn2lmAbNK6JKDDGw+HPzB5hLLkhhKlUgWt RyI32HSDViYX78hqfQdvIrlF8V0ciFdwLzBUPkw8Y9o2jfkpJwhGFo4oYBRlO56FYpab 9GPTQh84DY7qg9muDfY24sN+/xnW0MoEzEKYekMuDBaR5OWT8FBh1GfZKA9Gd49nWAb3 eGHJuJKJaPjs86Hu3/loFqcgPIalWy3KKOfSR2zlETOBmvHDDOBekNARUdicHXAkylku xg== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 30s1gmsujw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 02 May 2020 23:10:06 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 042N8ON1082568; Sat, 2 May 2020 23:10:06 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 30s06jahvb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 02 May 2020 23:10:06 +0000 Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 042NA4iR014234; Sat, 2 May 2020 23:10:04 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=9609 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 suspectscore=18 mlxlogscore=992 phishscore=0 spamscore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005020205 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9609 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=18 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-2005020205 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/02 18:16:52 X-ACL-Warn: Detected OS = Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.85 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:248605 Archived-At: > > If all string manipulations are to have prefix `string-' >=20 > No we will never put *all* string manipulation under the "string-" > prefix, simply because there's no way to precisely define what is "all > string manipulation". Good. You did speak of a time when "people got used to expect all string manipulations to appear there." They'll expect them all to be there, but they won't all be there. Then we can have another round of this topic, responding to queries about those that don't appear there... ;-) =20 > We know that we can't classify everything correctly. You're right about that. Starting with no agreement about what "correctly" is for any given case, and continuing through there not being any single "correctly" for many cases. To be clear and more serious: In general I'm in favor of the most relevant terms appearing in function etc. names. Usually that's already the case, but there are no doubt lots of poorly named functions. Sometimes there's an order that's more natural or expected - word order similar to what's spoken, for example. And sometimes (often) the order really doesn't matter - _especially_ for discovery. But sometimes, sure, there's no reason not to use a more standardized order. Whether and when that standardization should privilege the type of objects involved or the action involved is another question. I do expect that the proposed initiative (no, it's not formulated yet, but the impetus is there) will likely be a waste of time and doesn't represent a big problem to be solved. And I suspect the cure might be as bad, in the end, as the problem it tries to solve, or at best, it'll be a wash. To me it makes more sense for specific problematic names to be reported - as bugs or enhancement requests. Patch this or that real hole in the bikeshed roof, rather than repaint it. Even that (fixing this or that problematic name) has proved difficult to get done in the past.