From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?utf-8?B?7KGw7ISx67mI?= Newsgroups: gmane.emacs.devel Subject: Re: Namespaces - summary, conclusion Date: Mon, 4 May 2020 23:59:59 +0900 Message-ID: References: Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="30214"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Kangas , Emacs developers To: Philippe Vaucher Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 04 17:02:07 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 1jVcbe-0007js-Jd for ged-emacs-devel@m.gmane-mx.org; Mon, 04 May 2020 17:02:06 +0200 Original-Received: from localhost ([::1]:42556 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVcbd-0004Mh-Il for ged-emacs-devel@m.gmane-mx.org; Mon, 04 May 2020 11:02:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53788) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVcZz-0002Xq-4K for emacs-devel@gnu.org; Mon, 04 May 2020 11:00:25 -0400 Original-Received: from pv50p00im-tydg10021701.me.com ([17.58.6.54]:32807) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVcZx-0005mB-Lc for emacs-devel@gnu.org; Mon, 04 May 2020 11:00:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1588604407; bh=YwwIlREYG4q5fBwPLrKEu6A9fpAGNf2u7dBCSzTqZPc=; h=Content-Type:Subject:From:Date:Message-Id:To; b=j81sarHw/Gq2e20SWs164AroDDnl47NHtYcBltRcjM8N15qxSf4RUdIhjlSYr71FV ysGvU1w+TMShIu6P2UxIe+Ze1ya7eaSwbHj9v/foBmPp3pKrYQzgBRlxRnKQPFK56S J3ZHR+jXXvzd5AIsmWy9xCZJBLLXU1aWyNf9F7qK2wY7g4UAo97mIhxgbRyDHzxgeb Mt4Uia7SkfyaUQBoYmp4zCJ6IZC9fd6b1PHns+Ra3qDxJ4diopkt57fz5QneG7eozu iJgPOlecK+ogKU+dYxZ9ClVFbuNLwrXJ4Q3ulgVK7CgyX81zbyiEwo2tH5UPngREqj DQPI72gSw4d+A== Original-Received: from [192.168.0.2] (unknown [1.230.108.64]) by pv50p00im-tydg10021701.me.com (Postfix) with ESMTPSA id 694A7840738; Mon, 4 May 2020 15:00:06 +0000 (UTC) In-Reply-To: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-05-04_09:2020-05-04, 2020-05-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=529 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2005040124 Received-SPF: pass client-ip=17.58.6.54; envelope-from=pcr910303@icloud.com; helo=pv50p00im-tydg10021701.me.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/04 11:00:08 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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:248835 Archived-At: Philippe Vaucher 작성: >>> Given this is more or less the position held by Alan, Eli, Richard, >>> Drew and João I think the chances of seeing new aliases is close to 0. >> >> This is not my conclusion. I've seen several calls to move away from >> from discussing in the abstract to discuss specific, concrete >> examples. I think this is a good idea, since IMHO the abstract >> discussion is likely exhausted. >> >> There is always the chance that some of the proposals will be voted >> down. But also consider that some who have disagreed with you in the >> abstract might be more convinced by specific, concrete proposals. > > So far the string- proposal got shot down entirely. The regexp one was > initially a no-go from Alan but I then Richard kinda liked it and > proposed adaptations. > > @Stefan Monnier: I see that you talked about `multibyte-string-p` > already (and iirc that didn't went well. You talked earlier about > `process-`, maybe you'd like to propose some changes there? I think for people to propose changes and get them adapted, we first have to have some proper goals to target. So there are a few people here who think renaming some functions is beneficial - but everybody’s reasoning is different here. Some people who are opposed to renaming are a bit confused. I think the two big goals are consistency and discoverability. And then there are various small arguments like it’s easier to use prefix based completion and function search, it’s easier to guess, namespace means less function name clashing, etc… I think consistency is important, and if the language itself wants naming things the ‘lisp-way’, I’m fine with a consistent naming scheme. I’m not sure if you’d agree or not, but maybe trying to find a consistent naming scheme and documenting them (which was called as the ‘lisp-way’ by some) might be first. And then we can rename the ones that don’t follow them. > I mean I'm willing to propose concrete changes but if it's not obvious > for string- and regexp- why would it be for other topics? Let's try > another topic just to see: > > rename-file -> file-rename > delete-file -> file-delete > copy-file -> file-copy > expand-file-name -> file-expand-name > > Do you think people will be ok with that? The reason why I said about finding the naming scheme was because both the function name rename-file and file-truename makes sense to me. I think some preliminary conventions that Elisp already follows is that the - scheme is for actions on the object like rename-file or clear-string, and - scheme is for getting properties of the object like string-width and file-name-extension. (I’m not considering polymorphic ones.) But then there are exceptions, like string-trim (which should then be trim-string) or string-join (which should then be join-string). What does everybody think about this? I think it would be less disruptive and controversial if some Elisp core API guidelines are decided, written, and followed in the future. Then, if it turns out it’s useful enough, we can start aliasing functions that don’t follow them to names that do follow them (if it’s desirable to do so.) > Philippe