From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Re: Relevance search in Emacs Date: Sun, 6 Dec 2020 07:59:37 +0300 Message-ID: References: <6c90a70c6073bf3de6923168b0c277da@isnotmyreal.name> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16509"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: help-gnu-emacs@gnu.org To: TRS-80 Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 06 06:03:56 2020 Return-path: Envelope-to: geh-help-gnu-emacs@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 1klmDD-0004BK-40 for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 06 Dec 2020 06:03:55 +0100 Original-Received: from localhost ([::1]:45300 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1klmDC-0004DO-2F for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 06 Dec 2020 00:03:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45662) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1klmCb-0004D9-6d for help-gnu-emacs@gnu.org; Sun, 06 Dec 2020 00:03:17 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:51219) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1klmCY-0008E9-0U for help-gnu-emacs@gnu.org; Sun, 06 Dec 2020 00:03:16 -0500 Original-Received: from localhost ([::ffff:197.157.0.57]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0006.000000005FCC660E.000048D5; Sun, 06 Dec 2020 05:03:09 +0000 Content-Disposition: inline In-Reply-To: <6c90a70c6073bf3de6923168b0c277da@isnotmyreal.name> Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: 14 X-Spam_score: 1.4 X-Spam_bar: + X-Spam_report: (1.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:126079 Archived-At: * TRS-80 [2020-12-06 01:24]: > Also, I seem to recall hearing that there was some discussion about > moving some part (or all?) of Ivy directly into Emacs itself? I do know > that Ivy for a long time now have been assigning their copyrights to > GNU, they are very upfront about this to contributors at their GitHub in > fact. As ivy is in GNU ELPA those issues are already solved. It is up to author to polish the package if necessary to include it. But is not necessary as it is already in GNU ELPA and new packages can request it and it will be easier installed than from repositories not being straight in GNU Emacs. > Even those who would criticise Ivy/Helm[0] admit that there is a lot > more functionality that they offer than the "built-in" solutions. What Emacs needs is dynamic menu that user can filter quickly and work on it, it would be similar to dmenu X program but one can only choose one item there, or fzf console program which is more similar to what I mean. Helm and ivy and others try to be that. But we do not have very nice menu system in Emacs. And I do not refer to menu bar on top as such is limited, then not dynamic. Helm in full screen is pretty much what I think but again it limits itself to execution of it. Image list of items such as products. One need maybe to mark such and move from one category to other. Job is tedious by doing it with helm. List of people to which one need to send email by selecting them by hand. Helm offers C-SPC to select each item and then run TAB actions to do something with them. But programming with helm is wasting time pretty much. Doing it with tabulated-list-mode is so much easier: - filter items (provided function exist for this interface) - mark items (those are ID numbers) - do something with items For now I am transitioning from helm to tabulated-list-mode as for its simplicity and interface that remains on screen, it is does not disappear like completion interfaces (helm, ivy). It just lacks dynamic filtering. > realized this in developing some of my own (as yet unreleased) packages > where I depend on some of that functionality, and thus, in fact require > Ivy as a dependency. First I have started going helm dependency direction as that was first that I have discovered, then I have tried to make it that users can decide on completion. This is best approach and also does not bind myself to specific completion. Run it with built-in completion or turn any other completion package. It is best to have packages liberated from specific completion packages such as ivy, helm, etc. For me ivy does well with relevance search for few words apart from each other may be used to locate the item. But it is still "completion", it does not allow me actually work on the filtered set of items. It wants me to complete. I think helm too. > If this was more about search itself than choice of completion > framework, I guess I totally missed the point, or maybe that's another > discussion to have. > > Anyway, maybe give Ivy a try instead of Helm. Or if you are swayed by > arguments at my footnote link, one of those other "minimal" completion > frameworks. I am testing them all. Selectrum is just core stuff, it is not integrated well for end users and it is completion, not dynamic filter after filter. I hope you get what I mean.