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: [ELPA] New package: transient Date: Sun, 3 May 2020 03:10:50 +0900 Message-ID: References: <87368npxw4.fsf@bernoul.li> <87v9ljo5d0.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> <83v9leqmss.fsf@gnu.org> 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="38196"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , tomas@tuxteam.de, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 02 20:11:34 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 1jUwbu-0009q8-NC for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 20:11:34 +0200 Original-Received: from localhost ([::1]:38858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUwbt-0001BX-PR for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 14:11:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51022) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUwbK-00009O-D4 for emacs-devel@gnu.org; Sat, 02 May 2020 14:10:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUwbJ-0002TF-QR for emacs-devel@gnu.org; Sat, 02 May 2020 14:10:58 -0400 Original-Received: from pv50p00im-ztdg10012101.me.com ([17.58.6.49]:44861) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUwbJ-0002Rq-BU for emacs-devel@gnu.org; Sat, 02 May 2020 14:10:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1588443055; bh=sn75alDV886zZFiYG1pMeYJMkNymnvdajU7WqpIkNcg=; h=Content-Type:Subject:From:Date:Message-Id:To; b=rfz/lz9nUH/tN/GRv43PZQDr2JA3uJtv29ccqf3KOHdJr15P0abQIKIfSv71Rj4Fe uo8Y9GI8bA6LFTi3BOkSkgXMFsTwIrtGH0D6lXxGOCSDwJVKwhZ0sXWC0FDkVgqUbk taIFPYkyLyEvSzdHuWV6XpnqHuTP/SmO2wwNBnOd3iJRRQN/7t8vtoUOnq3tJJHKOu z6NXkPJoo1WlUjgcwO5/zivPJtFOzLX8cmR5lce9Jygk87sdPFP6wj+b8oDMDfj67x 7W6mwm0cz0w16+vs9uWaI3GMDY7N+ospWMZ347vhts517opm+rEl7lT3guxW6Bj6lf VIMMpxIRZxJRA== Original-Received: from [192.168.0.2] (unknown [1.230.108.64]) by pv50p00im-ztdg10012101.me.com (Postfix) with ESMTPSA id E022B84020A; Sat, 2 May 2020 18:10:53 +0000 (UTC) In-Reply-To: <83v9leqmss.fsf@gnu.org> 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-02_10:2020-05-01, 2020-05-02 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2005020162 Received-SPF: pass client-ip=17.58.6.49; envelope-from=pcr910303@icloud.com; helo=pv50p00im-ztdg10012101.me.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/02 14:10:56 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Received-From: 17.58.6.49 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:248517 Archived-At: Eli Zaretskii 작성: >> From: Stefan Monnier >> Cc: philippe.vaucher@gmail.com, tomas@tuxteam.de, rms@gnu.org, >> emacs-devel@gnu.org >> Date: Sat, 02 May 2020 12:48:33 -0400 >> >>>> Typical examples: is it `multibyte-string-p` or `string-multibyte-p`, >>>> `file-name-absolute-p` or `absolute-file-name-p`, ... ? >>> Then "C-u C-h a WORDS..." is your friend. >> >> Nope, way too slow. > > Is that the only problem? then let's speed it up, and Bob's our uncle. My understanding is that slow here means that opening a new *Apropos* buffer is an small, but additional mental burden when writing code, and it slows down writing code. >> I shouldn't have to do anything more than `str-mul TAB`. > > If you remembered the function's name, yes. But that's not the use > case we are discussing here. I think there are a lot of use cases here buried in the flood of mail - but everyone has a different use case where the prefix-convention will work better. We’re not trying to say that Emacs’s documentation system is not useful. >>>> Yes, we can try and improve completion, but we have a real underlying >>>> problem of irregular naming and completion would just help us paper >>>> over it. >>> The command "C-u C-h d regexp RET" brings up 111 matching functions. >>> Who will have patience looking through that list, unless the likely >>> candidates are near the beginning? >> >> IIUC that means you agree with my argument? > > Of course not! I'm saying that "regular naming" will increase the > length of the candidate list. The regular naming scheme will mean that we can only search functions that start with regexp - since the searcher doesn’t need grep-regexp-alist or gmm-regexp-concat when trying to get regexp APIs. >>> I don't object to this. I'm just saying that the hope this will allow >>> you to quickly find that-function-you-almost-remember-the-name-of are >>> overly optimistic. >> >> We impose a prefix convention on the rest of the Elisp world, and while >> some authors don't like it, I find that it is not just useful much more >> generally than to avoid conflicts, so we should try and use it for >> Emacs's core as well. > > The prefix convention we impose has almost nothing to do with the > issue at hand, because the package's name in many (most?) cases says > nothing about its domain of application. E.g., take message.el or > tmm.el or windmove.el or tempo.el or xdg.el, to name just a few random > examples. > >> It's not a new opinion, BTW: I started doing that back in Emacs-21 with >> the newcomment.el package which tried to stick to the "comment-" prefix >> even for things which previously used a different name. > > Beginner's luck. Occasionally, this could just happen to work, when > the package's name happens to say something about its purpose. But > mostly it doesn't, as packages like the one whose name is in the > Subject clearly demonstrate.