From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis <bugs@gnu.support> Newsgroups: gmane.emacs.devel Subject: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator Date: Thu, 12 Nov 2020 12:13:23 +0300 Message-ID: <X6z8s0NKmxcj3ntF@protected.rcdrun.com> References: <m2sg9g5j2p.fsf@gmail.com> <fe70158f-d55a-010a-74ba-2f81d1bb7663@gmx.at> <837dqr27zs.fsf@gnu.org> <alpine.NEB.2.22.394.2011111803220453.17489@sdf.lonestar.org> <83361f22ah.fsf@gnu.org> <alpine.NEB.2.22.394.2011111926450453.27530@sdf.lonestar.org> <83sg9fzlto.fsf@gnu.org> <alpine.NEB.2.22.394.2011112128400453.4149@sdf.lonestar.org> <83r1ozz22j.fsf@gnu.org> <alpine.NEB.2.22.394.2011120932160453.28737@sdf.lonestar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32914"; 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 <eliz@gnu.org> To: Gregory Heytings <ghe@sdf.org> Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 12 10:14:25 2020 Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org> 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 <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>) id 1kd8gT-0008Ql-4u for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Nov 2020 10:14:25 +0100 Original-Received: from localhost ([::1]:57964 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>) id 1kd8gS-0007rv-1V for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Nov 2020 04:14:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47960) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <bugs@gnu.support>) id 1kd8fw-0007Sr-Pb for emacs-devel@gnu.org; Thu, 12 Nov 2020 04:13:52 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:48177) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <bugs@gnu.support>) id 1kd8fu-0004Db-GR; Thu, 12 Nov 2020 04:13:52 -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 00000000002C0005.000000005FACFCCB.00006509; Thu, 12 Nov 2020 09:13:47 +0000 Content-Disposition: inline In-Reply-To: <alpine.NEB.2.22.394.2011120932160453.28737@sdf.lonestar.org> 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." <emacs-devel.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>, <mailto:emacs-devel-request@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/emacs-devel> List-Post: <mailto:emacs-devel@gnu.org> List-Help: <mailto:emacs-devel-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>, <mailto:emacs-devel-request@gnu.org?subject=subscribe> Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org> Xref: news.gmane.io gmane.emacs.devel:259067 Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/259067> * Gregory Heytings via "Emacs development discussions. <emacs-devel@gnu.org> [2020-11-12 11:51]: > > > > > If someone wants to claim that display of completion candidates > > > > by icomplete-vertical, ivy, etc. is anywhere near as pretty as > > > > what you get when you click on the address bar of a browser and > > > > get the drop-down list of candidates, then I can only say that I > > > > cannot disagree more. > > > > > > But why??? I just tried Ivy again, AFAICS it has everything you > > > have in the drop-down list of a browser: the matching substring is > > > colorized, you can use the mouse to click on a candidate to select > > > it, you can use the mouse to scroll the list up and down... What am > > > I missing? > > > > The looks, the looks... > > > > 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. Please observe it again. Helm offers completion. It is related to minibuffer, but it is not minibuffer with verticla completion. Maybe there is such option, but it is not there by default which is good thing. If development of icomplete leans on that misunderstanding then I recommend reading helm's general concepts: https://github.com/emacs-helm/helm/wiki Quote: People often think helm is just something like ido but displaying completion in a vertical layout instead of an horizontal one, it is not, helm is much more powerful than that. - Helm is able to complete multiple lists dispatched in different sources against a pattern. - Helm allows executing an unlimited number of actions on candidates. - Helm allows marking candidates to execute chosen action against this set of candidates. - Helm can display its completion buffer in different window layouts and in separate frame. Read more: Helm Completion v.s. Emacs Completion Differences between the two often trip up new users. Emacs completion is based on the minibuffer. Helm completion is based on the completion window. Commentary: The last sentence above declares why it is useful. It does not rip apart user's interface. Please consider when enlarging minibuffer that you are already "splitting the window", maybe not technically but practically as the modeline jumps up. So if you are already splitting window practically and visibly then you can as well leave modeline down where it was and do the same and lean on that good principle of helm completion. More from helm: In default Emacs, interactivity happens in the minibuffer. Typing new characters filters candidates in the minibuffer. <tab> may try to complete the typed characters with a valid candidate. Hitting RET selects the current candidate from the minibuffer. In Helm, interactivity happens in the completion window, not the minibuffer Typing new characters filters candidates in the completion window. Type until the desired candidate is highlighted, or navigate to it using C-n. Hitting RET selects the currently highlighted item in the completion window. Helm interaction model Helm’s interactivity makes the <tab> key redundant for completion because the selection candidates are already made visible in the Helm completion window. So, tab completion is not supported. In Helm, <tab> is used to view available actions to be taken on a candidate. Because the <tab> key is so ingrained in the muscle memory of long-time Emacs users, transition to Helm’s interactive model requires: A conscious visual adjustment to look at the completion window, and A conscious mental adjustment to avoid using the <tab> key for completion and go straight to <RET> key to select a candidate. Helm’s approach to completion provides better visual cues, takes fewer keystrokes, and is much faster. Commentary: there is reason why is helm most useful package around for completion. Those are fundamental concepts it was built on. And I hope to see those more inside of Emacs.