From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: transient Date: Sun, 03 May 2020 17:45:08 +0300 Message-ID: <83zhapoz63.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="55482"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 03 16:46:27 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 1jVFsw-000EI3-9g for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 16:46:26 +0200 Original-Received: from localhost ([::1]:46478 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVFsu-00071b-UZ for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 10:46:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40734) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVFrw-00066S-O0 for emacs-devel@gnu.org; Sun, 03 May 2020 10:45:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53698) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVFrw-0000wO-F0; Sun, 03 May 2020 10:45:24 -0400 Original-Received: from [176.228.60.248] (port=1843 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jVFrn-0006mN-BX; Sun, 03 May 2020 10:45:15 -0400 In-Reply-To: (message from Stefan Monnier on Sat, 02 May 2020 16:39:57 -0400) 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:248692 Archived-At: > From: Stefan Monnier > Cc: philippe.vaucher@gmail.com, tomas@tuxteam.de, rms@gnu.org, > emacs-devel@gnu.org > Date: Sat, 02 May 2020 16:39:57 -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. > > 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. You seem to be measuring only the "speed" of your typing the input, and disregard the time required to look over the results of the completion or doc search and decide which is the one you want. By contrast, what's important for me is the total time it took me to request the completion/search and find the answer I was looking for. So if a few additional keystrokes will give me the answer much more quickly and accurately, it is a net win for me. > No, because it lets you use a more targeted (non-substring) matching, so > you'll have much fewer matches. I will believe this when I see it. For now, the proposals that are floating will bloat the list, not make it shorter, and the fuzzy matching in completion tends to bring more matches, not less. For me, any list where I don't find what I'm looking for within the first 2 dozen entries is "too long", and I tend to abandon it and look for alternative ways of finding what I want. > > 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. I'm talking about the packages we actually have, and your counter-argument seems to be that "in a better world" these difficulties wouldn't happen. But in this world they do happen: how can anyone remember whether some window-related function is in window.el, winner.el, or windmove.el? Are we supposed to learn all that by heart? > 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)." Maybe you should use and hack Emacs more ;-) Years of using Emacs with its superb documentation and elaborate facilities to find stuff in that documentation caused me to be more demanding, to expect better documentation that is easier to access quickly. I might compromise if something like that is not available when I'm working with other software, but I certainly don't want to give that up when I work on Emacs! And I'm astonished to hear that people don't _want_ the documentation we provide and the help commands to go with it, and are willing to settle for API completion!