From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: transient Date: Sat, 02 May 2020 16:39:57 -0400 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 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="11789"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 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 22:40:44 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 1jUywF-0002xW-Ls for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 22:40:43 +0200 Original-Received: from localhost ([::1]:33726 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUywE-0006Uk-MT for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 16:40:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33438) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUyvj-0005xX-9g for emacs-devel@gnu.org; Sat, 02 May 2020 16:40:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUyvi-0000U3-58 for emacs-devel@gnu.org; Sat, 02 May 2020 16:40:10 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:28926) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUyvg-0000Mt-B2; Sat, 02 May 2020 16:40:08 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 57D8E45085E; Sat, 2 May 2020 16:40:06 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BBB3F450838; Sat, 2 May 2020 16:40:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1588452004; bh=9RsWJXHaaXWZKbPHne+rgeGnfGarQ3b7j/PanqR6M7w=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=myI+iBh6pTgLIJZJvCST1RHL8RFoGgBA8l1Z3vcQDo400TyM9CFHy1y4q4ppD7fKN 39CoYToL1Uvk5J88eTP/Q3dLnhXCccyP05Kx+9+lO7zgda0drSyOR6wyG3Mrb+EiN2 /NToj++prsgFxMTNixnupwi0HJEIwIcw22VWzmUTV4+DHixkTNQ/tr2yUTSv4ZFNst j6Z9HMiCw733alb3Kh8b9FW3htFfXns38b6vVhEKJIZBAYqgf+SpNV7VayJWORjtB2 qw3K3SCuBA3R7/kITdpsVfIoItrxb+DKdBvWSXuvYYPb9opbMpKFgkc/8bLvTHF7QL 3vnieYVGsd0Zw== Original-Received: from alfajor (unknown [216.154.3.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 451B71206C2; Sat, 2 May 2020 16:40:04 -0400 (EDT) In-Reply-To: <83v9leqmss.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 02 May 2020 20:17:07 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/02 16:40:06 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 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:248563 Archived-At: >> >> 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. When I say "slow" I measure the time in number of hand movements. I'm in the middle of writing code, I might have already written `str` even and now I'd have to do `C-u C-h a str mul RET` and that will only display the answer, I still have to find it in the list and then arrange for it to make its way to my buffer. Compared to `-mul TAB`, I can't see any way the `C-h` route could be even remotely competitive. >> 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 remember it's a string manipulating function and it has "multibyte" in its name, so `str-mul` *should* find it (along with a few other candidates, probably), even if I can't remember the whole name. >> >> 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. No, because it lets you use a more targeted (non-substring) matching, so you'll have much fewer matches. Having a bit more or a bit less than 111 matches makes no difference: as you say "who will have patience looking through that list"? You need to narrow down that list and the only way to do it (short of removing existing functions) is to use a less permissive matching. > 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. That's only unhelpful in the case where you don't know the relevant prefix name. In such a situation, you definitely need to resort to some kind of manual to find your way to relevant library. A regular/structured naming system doesn't help for that, but it helps afterwards: once you know under which prefix things should be found, then you can find the relevant function more easily. >> 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. No, the actual name is irrelevant to my argument. What is relevant is that the *same* name is used, so the functions are grouped together in the namespace. Stefan "who finds this discussion enlightening, because he took it for granted that everyone knows that such structuring is *obviously* good (tho not necessarily always best)."