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.