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: Sat, 02 May 2020 21:45:10 +0300 Message-ID: <83k11uqiq1.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> <83r1w2qjf9.fsf@gnu.org> <11D00CDF-DDBF-4BB8-AF3F-ED0A8313E004@icloud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="61517"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org To: =?utf-8?B?7KGw7ISx67mI?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 02 20:46:24 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 1jUx9b-000Ft4-Fm for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 20:46:23 +0200 Original-Received: from localhost ([::1]:54494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUx9a-0000qI-II for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 14:46:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32772) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUx8i-0008R2-26 for emacs-devel@gnu.org; Sat, 02 May 2020 14:45:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36185) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUx8h-0005NC-J6; Sat, 02 May 2020 14:45:27 -0400 Original-Received: from [176.228.60.248] (port=4689 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jUx8Y-0003zL-8L; Sat, 02 May 2020 14:45:18 -0400 In-Reply-To: <11D00CDF-DDBF-4BB8-AF3F-ED0A8313E004@icloud.com> (message from =?utf-8?B?7KGw7ISx67mI?= on Sun, 3 May 2020 03:37:31 +0900) 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:248537 Archived-At: > From: 조성빈 > Date: Sun, 3 May 2020 03:37:31 +0900 > Cc: Stefan Monnier , > tomas@tuxteam.de, > rms@gnu.org, > emacs-devel@gnu.org > > Eli Zaretskii 작성: > > >> 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. > > > > How is that different from having *Completions* pop up instead? > > Which… is why a lot of people don’t use *Completion* and use company-mode Which does the same, just in a menu. How's that different? > > And how is looking up the function you need a "burden", when any > > modern IDE provides some way of showing the possible candidates for > > what you want to do next? > > Modern IDEs provide the candidates without needing to do any action. How's that relevant to the issue at hand? It's a tangent. > It’s very different from having to explicitly look up. No, it isn't. "Look up" means look through the list of candidates, applying some logic towards the decision which candidate to choose. > >> 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. > > > > Do they need rx, as just one example? > > I think that’s a different question. > (FWIW, I consider that rx shouldn’t appear.) Let's see how the re- renaming thread evolves, I'm not sure everyone will agree. > Whether or not the searcher wants to know about rx or not, > it’s probably true that one doesn’t want gmm-regexp-concat. Why not? Sounds like a very useful function for someone who works with regular expressions.