From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: solidius4747@gmail.com Newsgroups: gmane.emacs.help Subject: Re: A package in a league of its own: Helm Date: Fri, 29 Aug 2014 18:49:52 -0700 (PDT) Message-ID: References: <787f8d86-dede-4627-b4e5-3658a1833455@googlegroups.com> <73520ac0-9fc0-42ce-8a15-cc400b6f8308@googlegroups.com> <672a0d66-bc48-4b7a-9279-c7d631a03f79@googlegroups.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1409363426 17140 80.91.229.3 (30 Aug 2014 01:50:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Aug 2014 01:50:26 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Aug 30 03:50:22 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XNXo4-0003C9-Eo for geh-help-gnu-emacs@m.gmane.org; Sat, 30 Aug 2014 03:50:20 +0200 Original-Received: from localhost ([::1]:44944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNXo3-0004Qc-FR for geh-help-gnu-emacs@m.gmane.org; Fri, 29 Aug 2014 21:50:19 -0400 X-Received: by 10.236.36.99 with SMTP id v63mr1321107yha.2.1409363392810; Fri, 29 Aug 2014 18:49:52 -0700 (PDT) X-Received: by 10.50.66.135 with SMTP id f7mr160029igt.3.1409363392704; Fri, 29 Aug 2014 18:49:52 -0700 (PDT) Original-Path: usenet.stanford.edu!i13no4277429qae.1!news-out.google.com!ef6ni0igb.0!nntp.google.com!r2no10315675igi.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=14.161.13.65; posting-account=c2AWuQoAAACA36o69JJJEmXY5MOg4YNp Original-NNTP-Posting-Host: 14.161.13.65 User-Agent: G2/1.0 Injection-Date: Sat, 30 Aug 2014 01:49:52 +0000 Original-Xref: usenet.stanford.edu gnu.emacs.help:207252 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:99529 Archived-At: =20 > 99.9% of the time I work on projects that I worked on previously and >=20 > hence I know its structure. Knowing the *precise* structure is not >=20 > really required as you can type just the part that is characteristic >=20 > enough (the ordering matters, though, as you mentioned.) Having a method >=20 > that minimizes the amount of text that I have to write is very >=20 > convenient. Since I started using Helm, I never bother to remember the structure of my = working directory. And that's the point: I don't have to remember such triv= ial details and I can focus my mind on other more important things. =20 >=20 > For your query about the existence of a main.c file for the x86 arch, I >=20 > would type "x86main.c". The answer should be evident by just looking at >=20 > the first match. (Acually, "xmac" should be enough if you are willing to >=20 > look beyond the first match.) And what if it doesn't exist? You will have to move point at the beginning = and delete whole thing. With ido, you are constrained by its ordering: you = cannot immediately enter what you directly one, such as an arbitrary file, = and refine later. If there are a large pool of candidates, you have to move= point at the beginning and start typing additional information. Worse, you= maybe to move point to type something in between. Suddenly it's not so con= venient to find something anymore. And ido is not particularly suit for nar= rowing large set of candidates with complex query. Here is another example that make sure of Helm interface nicely: helm-seman= tic-or-imenu. Demo: http://tuhdo.github.io/static/part3/helm-semantic-or-im= enu.gif You can think of it as an outline tree in regular IDE, but Helm makes it in= teractive, and fast. I can ask question like "is there something that is fu= nction and has int in it that the function name contains memory?". Here is another demo on Helm's homepage: https://github.com/emacs-helm/helm= #advanced-usage Finally, the strings in Helm are not just strings; they are regexp and I th= ink they are more powerful then normal fuzzy matcher. >=20 > I get your point about incrementally refining the query and I realize >=20 > that it can be more convenient than flx for certain uses (such as when >=20 > exploring a large set of previously unknown candidates.) It's only that >=20 > the flx way is more convenient on my case, where I always work on a >=20 > semi-known set of candidates. Sure, it could be more productive for things you work regularly. But I like= a general interface that can deal with both known and unknown environment.