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.devel Subject: Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator Date: Thu, 12 Nov 2020 13:25:35 +0300 Message-ID: References: <837dqr27zs.fsf@gnu.org> <83361f22ah.fsf@gnu.org> <83sg9fzlto.fsf@gnu.org> <83r1ozz22j.fsf@gnu.org> 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="4175"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: spacibba@aol.com, andreyk.mad@gmail.com, emacs-devel@gnu.org, rudalics@gmx.at, monnier@iro.umontreal.ca, Eli Zaretskii To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 12 11:46:11 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 1kdA7H-000107-R2 for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Nov 2020 11:46:11 +0100 Original-Received: from localhost ([::1]:56854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdA7G-0004Y3-Rk for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Nov 2020 05:46:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdA6j-00046X-LO for emacs-devel@gnu.org; Thu, 12 Nov 2020 05:45:37 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:33863) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdA6h-0002xF-As; Thu, 12 Nov 2020 05:45:37 -0500 Original-Received: from localhost ([::ffff:197.157.34.177]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0009.000000005FAD1249.00006BD8; Thu, 12 Nov 2020 10:45:26 +0000 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/12 01:55:17 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:259070 Archived-At: * Gregory Heytings [2020-11-12 12:20]: > > > > This is very subjective. I find the looks of the minibuffer with > > > vertical completions very nice, and given the popularity of packages > > > that implement that feature (Helm and Ivy) I'm sure I'm not alone. > > > And, FWIW, I would very much dislike a "combo box like UI" to > > > replace this. > > > > Helm does not offer minibuffer with vertical completions. > > > > I know. But for the purpose of _this_ discussion (prettyness of a vertical > presentation of completion candidates by Emacs compared to other software) > what it does is the same. icomplete vertical completion is not same to helm completion. Maybe you did not see or did not observe the difference which is to me very substantial. I wish icomplete would be in that sense same to helm, but it is not. I am asking if it can be made, please if possible. It would be alright to me if bounties can be made and accepted for work. There is nothing wrong in supporting people with donations. Features wanted in ivy or icomplete or anything inside of Emacs or in GNU ELPA: - full frame completion with mode line staying where it is - split window completion as helm does it, with mode line staying where it should be My purpose is to possibly benefit people who will be doing researches and projects. And that is one of fundamental functions. It need not be implemented as "minibuffer completion", not at all. It can be implementd any how. Small buffer for completions can as well appear on the top of the window while real time displaying and narrowing is shown below. I also prefer tabulated-list-mode to have the feature to narrow or filter lines: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44550