A package in a league of its own: Helm

A package in a league of its own: Helm

[solidius4747]

I wrote a guide for Helm here: http://tuhdo.github.io/helm-intro.html

Hope it help with your Helm usage if you are new to Helm.

Guide for package use?(was A package in a league of its own: Helm)

[Rusi]

On Friday, August 29, 2014 9:48:33 AM UTC+5:30, solidi...@gmail.com wrote:
> I wrote a guide for Helm here: http://tuhdo.github.io/helm-intro.html
> 
> 
> Hope it help with your Helm usage if you are new to Helm.

Hey Solidius you seem to be doing good work!
There are some oldtimers (like myself) who need an intro to the
new-n-shiny packaging system. How about a tutorial on that?

I started reading up on that then found on the org-mode list (org is
one of my biggest uses of emacs) that org is too large to fit
neatly into the packaging framework. At that point I decided to postpone switching and wait...

Re: Guide for package use?(was A package in a league of its own: Helm)

[solidius4747]

@Rusi I wrote the guide here: http://tuhdo.github.io/emacs-tutor3.html#sec-4-1

The guide is about using the package manager to install, not to write and contribute packages.

Vào 12:49:40 UTC+7 Thứ sáu, ngày 29 tháng tám năm 2014, Rusi đã viết:
> On Friday, August 29, 2014 9:48:33 AM UTC+5:30, solidi...@gmail.com wrote:
> 
> > I wrote a guide for Helm here: http://tuhdo.github.io/helm-intro.html
> 
> > 
> 
> > 
> 
> > Hope it help with your Helm usage if you are new to Helm.
> 
> 
> 
> Hey Solidius you seem to be doing good work!
> 
> There are some oldtimers (like myself) who need an intro to the
> 
> new-n-shiny packaging system. How about a tutorial on that?
> 
> 
> 
> I started reading up on that then found on the org-mode list (org is
> 
> one of my biggest uses of emacs) that org is too large to fit
> 
> neatly into the packaging framework. At that point I decided to postpone switching and wait...

Re: A package in a league of its own: Helm

[Óscar Fuentes]

solidius4747@gmail.com writes:

> I wrote a guide for Helm here: http://tuhdo.github.io/helm-intro.html
>
> Hope it help with your Helm usage if you are new to Helm.

Helm looks impressive.

I have a mature completion environment around ido+flx. One of the killer
features is to quickly navigate huge lists of completion candidates. For
instance, while on a git repo a command allows me to locate a versioned
file, typically taking about 2 seconds for a tree containing tens of
thousands of files. The command is very simple to implement (9 lines).

How difficult is to add a new completion command to helm? Such as
providing it with a list of strings and complete on it?

Can helm use other completion matching methods, such as flx? I regard
flx as more convenient than helm's default matching system.

Re: A package in a league of its own: Helm

[solidius4747]

Vào 20:36:32 UTC+7 Thứ sáu, ngày 29 tháng tám năm 2014, Óscar Fuentes đã viết:
> solidius4747@gmail.com writes:
> 
> 
> 
> > I wrote a guide for Helm here: http://tuhdo.github.io/helm-intro.html
> 
> >
> 
> > Hope it help with your Helm usage if you are new to Helm.
> 
> 
> 
> Helm looks impressive.
> 
> 
> 
> I have a mature completion environment around ido+flx. One of the killer
> 
> features is to quickly navigate huge lists of completion candidates. For
> 
> instance, while on a git repo a command allows me to locate a versioned
> 
> file, typically taking about 2 seconds for a tree containing tens of
> 
> thousands of files. The command is very simple to implement (9 lines).
> 
> 
> 
> How difficult is to add a new completion command to helm? Such as
> 
> providing it with a list of strings and complete on it?
> 
> 
> 
> Can helm use other completion matching methods, such as flx? I regard
> 
> flx as more convenient than helm's default matching system.

Helm is quite fast. I tried it on the Linux kernel, and Helm can display all 46678 files and navigation (like move to next/previous line or <next>/<prior>) is still fast, but not feel as "smooth". If you have anything under 30000 candidates, everything behaves normally. You can try with Projectile using projectile-find-file to list all files. Be sure to set helm-candidate-number-limit to 30000 and set projectile-completion-system to Helm.

You may also interest in "Why Helm is powerful" section

Re: A package in a league of its own: Helm

[solidius4747]

Vào 20:36:32 UTC+7 Thứ sáu, ngày 29 tháng tám năm 2014, Óscar Fuentes đã viết:
> solidius4747@gmail.com writes:
> 
> 
> 
> > I wrote a guide for Helm here: http://tuhdo.github.io/helm-intro.html
> 
> >
> 
> > Hope it help with your Helm usage if you are new to Helm.
> 
> 
> 
> Helm looks impressive.
> 
> 
> 
> 
> How difficult is to add a new completion command to helm? Such as
> 
> providing it with a list of strings and complete on it?
> 
> 
> 
> Can helm use other completion matching methods, such as flx? I regard
> 
> flx as more convenient than helm's default matching system.

It should be easy. I've never tried to provide custom source but if you use existing Helm sources, it's very easy to craft your own. For me, I prefer Helm's way. That is, I can directly enter a filename, and narrow down it later if more than one candidates are displayed. Compared with ido + flx, I have to precisely remember the structure of something and enter it follow the correct order. For example, I can enter test.c and hundreds of them might exist. I can narrow down further by specifying the path incrementally later. With Ido, I always have to remember the path for fuzzy completion. Helm gives me greater flexibility; with flexibility, it gives greater explorability in a huge source. You should read the section "Why Helm is powerful" above.

Re: A package in a league of its own: Helm

[Óscar Fuentes]

solidius4747@gmail.com writes:

>> How difficult is to add a new completion command to helm? Such as
>> 
>> providing it with a list of strings and complete on it?
>> 
>> 
>> 
>> Can helm use other completion matching methods, such as flx? I regard
>> 
>> flx as more convenient than helm's default matching system.
>
> It should be easy. I've never tried to provide custom source but if
> you use existing Helm sources, it's very easy to craft your own.

I guess that you are talking about the difficulty of adding a new
completion command here.

> For
> me, I prefer Helm's way. That is, I can directly enter a filename, and
> narrow down it later if more than one candidates are displayed.
> Compared with ido + flx, I have to precisely remember the structure of
> something and enter it follow the correct order. For example, I can
> enter test.c and hundreds of them might exist. I can narrow down
> further by specifying the path incrementally later. With Ido, I always
> have to remember the path for fuzzy completion. Helm gives me greater
> flexibility; with flexibility, it gives greater explorability in a
> huge source. You should read the section "Why Helm is powerful" above.

Okay. I have a different view here (and your description of flx
requiring to precisely remenbering the structure of your target is not
accurate, in my experience.) I would never switch from ido+flx if the
alternative does nor provide the same fuzzy matching capabilities. After
investigating a bit, the bad news is that incorporating flx into helm is
not easy at all. The good news is that there are a significant interest
on doing it, including flx's author. Let's see how this evolves.

Thanks for answering my questions.

Re: A package in a league of its own: Helm

[solidius4747]

> 
> Okay. I have a different view here (and your description of flx
> 
> requiring to precisely remenbering the structure of your target is not
> 
> accurate, in my experience.) I would never switch from ido+flx if the
> 
> alternative does nor provide the same fuzzy matching capabilities. After
> 
> investigating a bit, the bad news is that incorporating flx into helm is
> 
> not easy at all. The good news is that there are a significant interest
> 
> on doing it, including flx's author. Let's see how this evolves.
> 
> 
> 
> Thanks for answering my questions.

Consider this path: arch/x86/boot/main.c

Can you type the file name first: "main.c", then add "x86" to get the correct file above? I'm pretty sure ido+flx can't do that, but maybe I'm missing something.

With Helm, you can simply specify "mai x86" and it narrows to 3 candidates with the above path at the top. The file is in Linux kernel source.

Maybe you misunderstood my statement about precise remembering project structure. What I meant was you have to remember the correct path ordering, and that requires you to be familiar with the directory structure. Whlie in Helm, I'm completely new to a directory and simply know nothing about directory structure. With Helm, I can start pop up questions like "is there a main.c that is relate to x86 arch?" and so on.

Re: A package in a league of its own: Helm

[Óscar Fuentes]

solidius4747@gmail.com writes:

> Consider this path: arch/x86/boot/main.c
>
> Can you type the file name first: "main.c", then add "x86" to get the
> correct file above? I'm pretty sure ido+flx can't do that, but maybe
> I'm missing something.
>
> With Helm, you can simply specify "mai x86" and it narrows to 3
> candidates with the above path at the top. The file is in Linux kernel
> source.
>
> Maybe you misunderstood my statement about precise remembering project
> structure. What I meant was you have to remember the correct path
> ordering, and that requires you to be familiar with the directory
> structure. Whlie in Helm, I'm completely new to a directory and simply
> know nothing about directory structure. With Helm, I can start pop up
> questions like "is there a main.c that is relate to x86 arch?" and so
> on.

99.9% of the time I work on projects that I worked on previously and
hence I know its structure. Knowing the *precise* structure is not
really required as you can type just the part that is characteristic
enough (the ordering matters, though, as you mentioned.) Having a method
that minimizes the amount of text that I have to write is very
convenient.

For your query about the existence of a main.c file for the x86 arch, I
would type "x86main.c". The answer should be evident by just looking at
the first match. (Acually, "xmac" should be enough if you are willing to
look beyond the first match.)

I get your point about incrementally refining the query and I realize
that it can be more convenient than flx for certain uses (such as when
exploring a large set of previously unknown candidates.) It's only that
the flx way is more convenient on my case, where I always work on a
semi-known set of candidates.

Re: A package in a league of its own: Helm

[solidius4747]

 
> 99.9% of the time I work on projects that I worked on previously and
> 
> hence I know its structure. Knowing the *precise* structure is not
> 
> really required as you can type just the part that is characteristic
> 
> enough (the ordering matters, though, as you mentioned.) Having a method
> 
> that minimizes the amount of text that I have to write is very
> 
> 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 trivial details and I can focus my mind on other more important things.
 
> 
> For your query about the existence of a main.c file for the x86 arch, I
> 
> would type "x86main.c". The answer should be evident by just looking at
> 
> the first match. (Acually, "xmac" should be enough if you are willing to
> 
> 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 convenient to find something anymore. And ido is not particularly suit for narrowing large set of candidates with complex query.

Here is another example that make sure of Helm interface nicely: helm-semantic-or-imenu. Demo: http://tuhdo.github.io/static/part3/helm-semantic-or-imenu.gif

You can think of it as an outline tree in regular IDE, but Helm makes it interactive, and fast. I can ask question like "is there something that is function 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 think they are more powerful then normal fuzzy matcher.

> 
> I get your point about incrementally refining the query and I realize
> 
> that it can be more convenient than flx for certain uses (such as when
> 
> exploring a large set of previously unknown candidates.) It's only that
> 
> the flx way is more convenient on my case, where I always work on a
> 
> 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.

Re: A package in a league of its own: Helm

[Óscar Fuentes]

solidius4747@gmail.com writes:

[snip]

> 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.

Speaking of that, it would be a good thing that helm supported multiple
filtering methods.

As you write on terms of helm vs ido I'll clarify that I'm referring to
flx (not to be confused with ido's flex matching) which is a generic
method that supports ido but which is not tied to it.

The algorithm that takes the user input and a set of candidates and
outputs a new set of canditates performs a task that is orthogonal to
the rest of helm/ido.

If helm allowed to configure the default filter method for each source
(with a global default) and also allowed to switch it on the fly (as ido
does) the users could select what best suit them on a case-by-case
basis.

Re: A package in a league of its own: Helm

[solidius4747]

> 
> As you write on terms of helm vs ido I'll clarify that I'm referring to
> 
> flx (not to be confused with ido's flex matching) which is a generic
> 
> method that supports ido but which is not tied to it.

Yes, I used ido + flx package for a long time before I understood Helm (prior Anything) and switch to Helm permanently. Basically flx allows you to fuzzy match like some vim or sublime text plugins. But none like Helm exists in those editors.

But then, the way Helm is doing gives it greater flexibility. I doubt that if Helm does not match the way it currently is, it's not Helm anymore. Even so, without Helm matching, it still allows you to do interesting things with its interactive interface. For example:

- interactive grep: http://tuhdo.github.io/static/live_grep.gif
- interactive occur: http://tuhdo.github.io/static/part3/helm-occur.gif
- interactive kill ring: http://tuhdo.github.io/static/part3/helm-kill-ring.gif
- interactive mark ring: http://tuhdo.github.io/helm-intro.html#sec-15
 
> 
> The algorithm that takes the user input and a set of candidates and
> 
> outputs a new set of canditates performs a task that is orthogonal to
> 
> the rest of helm/ido.

The author of flx (Le Wang) used flx along with Helm's filtering method before, but he did not know how to enable appropriate highlighting in Helm that can guide the user: https://github.com/lewang/flx/issues/59

> 
> If helm allowed to configure the default filter method for each source
> 
> (with a global default) and also allowed to switch it on the fly (as ido
> 
> does) the users could select what best suit them on a case-by-case
> 
> basis.

You can fuzzy match with helm-find-files (in current directory) or helm-buffer-lists. Maybe you should ask Le Wang or join Helm group to customize your search method.

Re: A package in a league of its own: Helm

[Phillip Lord]

First, thanks for the tutorial. I've tried helm (and anything) several
times, but never got on with it as I have found the experience too
confusing. I've always reverted to ido. I like the idea of helm because
it is more pervasive than ido and can do several things at once. I
dislike the practice of helm because too many things happen at once (and
the wiki is incomprehensible).

The thing that I am stuck on at the moment, is file navigation. With
ido.el, I use [tab] or [del] to move up or down directories (and carry
on selecting). With helm I have to use C-l C-j which I find much slower
because of the double keypress and because C-k is in the middle.

I don't get the behaviour you are talking about with helm. I get a
single directory at once, and I have to navigate through it to get to
the files I want.

Clearly I doing something wrong!

Phil



<solidius4747@gmail.com> writes:
> Consider this path: arch/x86/boot/main.c
>
> Can you type the file name first: "main.c", then add "x86" to get the correct
> file above? I'm pretty sure ido+flx can't do that, but maybe I'm missing
> something.
>
> With Helm, you can simply specify "mai x86" and it narrows to 3 candidates
> with the above path at the top. The file is in Linux kernel source.
>
> Maybe you misunderstood my statement about precise remembering project
> structure. What I meant was you have to remember the correct path ordering,
> and that requires you to be familiar with the directory structure. Whlie in
> Helm, I'm completely new to a directory and simply know nothing about
> directory structure. With Helm, I can start pop up questions like "is there a
> main.c that is relate to x86 arch?" and so on.
>
>

-- 
Phillip Lord,                           Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,               skype: russet_apples
Newcastle University,                   twitter: phillord
NE1 7RU                                 

Re: A package in a league of its own: Helm

[York Zhao]

I've been using Helm for many years, and it has been a fundamental part of my
Emacs system. However, I also don't like `helm-find-file', and I agree ido is
much better in this. By the way, in `helm-find-file', you may want to try using
the left arrow to go to the parent directory, not as good as in ido but still
usable. Having said that, I think other than "find file", helm is great in
anything else.

On Mon, Sep 1, 2014 at 12:01 PM, Phillip Lord
<phillip.lord@newcastle.ac.uk> wrote:
>
> First, thanks for the tutorial. I've tried helm (and anything) several
> times, but never got on with it as I have found the experience too
> confusing. I've always reverted to ido. I like the idea of helm because
> it is more pervasive than ido and can do several things at once. I
> dislike the practice of helm because too many things happen at once (and
> the wiki is incomprehensible).
>
> The thing that I am stuck on at the moment, is file navigation. With
> ido.el, I use [tab] or [del] to move up or down directories (and carry
> on selecting). With helm I have to use C-l C-j which I find much slower
> because of the double keypress and because C-k is in the middle.
>
> I don't get the behaviour you are talking about with helm. I get a
> single directory at once, and I have to navigate through it to get to
> the files I want.
>
> Clearly I doing something wrong!
>
> Phil
>
>
>
> <solidius4747@gmail.com> writes:
>> Consider this path: arch/x86/boot/main.c
>>
>> Can you type the file name first: "main.c", then add "x86" to get the correct
>> file above? I'm pretty sure ido+flx can't do that, but maybe I'm missing
>> something.
>>
>> With Helm, you can simply specify "mai x86" and it narrows to 3 candidates
>> with the above path at the top. The file is in Linux kernel source.
>>
>> Maybe you misunderstood my statement about precise remembering project
>> structure. What I meant was you have to remember the correct path ordering,
>> and that requires you to be familiar with the directory structure. Whlie in
>> Helm, I'm completely new to a directory and simply know nothing about
>> directory structure. With Helm, I can start pop up questions like "is there a
>> main.c that is relate to x86 arch?" and so on.
>>
>>
>
> --
> Phillip Lord,                           Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
> School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower,               skype: russet_apples
> Newcastle University,                   twitter: phillord
> NE1 7RU
>

Re: A package in a league of its own: Helm

[Phillip Lord]

Left and right arrow! That's useful to know. Still not as convienient as
tab and return (espectially on laptops), but better than double presses.

Phil

York Zhao <gtdplatform@gmail.com> writes:
> I've been using Helm for many years, and it has been a fundamental part of my
> Emacs system. However, I also don't like `helm-find-file', and I agree ido is
> much better in this. By the way, in `helm-find-file', you may want to try using
> the left arrow to go to the parent directory, not as good as in ido but still
> usable. Having said that, I think other than "find file", helm is great in
> anything else.
>
> On Mon, Sep 1, 2014 at 12:01 PM, Phillip Lord
> <phillip.lord@newcastle.ac.uk> wrote:
>>
>> First, thanks for the tutorial. I've tried helm (and anything) several
>> times, but never got on with it as I have found the experience too
>> confusing. I've always reverted to ido. I like the idea of helm because
>> it is more pervasive than ido and can do several things at once. I
>> dislike the practice of helm because too many things happen at once (and
>> the wiki is incomprehensible).
>>
>> The thing that I am stuck on at the moment, is file navigation. With
>> ido.el, I use [tab] or [del] to move up or down directories (and carry
>> on selecting). With helm I have to use C-l C-j which I find much slower
>> because of the double keypress and because C-k is in the middle.
>>
>> I don't get the behaviour you are talking about with helm. I get a
>> single directory at once, and I have to navigate through it to get to
>> the files I want.
>>
>> Clearly I doing something wrong!
>>
>> Phil
>>
>>
>>
>> <solidius4747@gmail.com> writes:
>>> Consider this path: arch/x86/boot/main.c
>>>
>>> Can you type the file name first: "main.c", then add "x86" to get the correct
>>> file above? I'm pretty sure ido+flx can't do that, but maybe I'm missing
>>> something.
>>>
>>> With Helm, you can simply specify "mai x86" and it narrows to 3 candidates
>>> with the above path at the top. The file is in Linux kernel source.
>>>
>>> Maybe you misunderstood my statement about precise remembering project
>>> structure. What I meant was you have to remember the correct path ordering,
>>> and that requires you to be familiar with the directory structure. Whlie in
>>> Helm, I'm completely new to a directory and simply know nothing about
>>> directory structure. With Helm, I can start pop up questions like "is there a
>>> main.c that is relate to x86 arch?" and so on.
>>>
>>>
>>
>> --
>> Phillip Lord,                           Phone: +44 (0) 191 222 7827
>> Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
>> School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
>> Room 914 Claremont Tower,               skype: russet_apples
>> Newcastle University,                   twitter: phillord
>> NE1 7RU
>>
>
>

-- 
Phillip Lord,                           Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,               skype: russet_apples
Newcastle University,                   twitter: phillord
NE1 7RU                                 

Re: A package in a league of its own: Helm

[Tu, Do]

I think helm-find-files is much better than stock ido-find-file or even ido-find-file because:

- It has fuzzy matching by default. You have to install flx to get fuzzy matching in ido.
- Some people find that Ido horizontal listing is messy, so they create `ido-vertical-mode` for cleaner looking. With Helm, you get this by default with its interface. If you worry the Helm buffer is a bit big, you can always customize its size.
- It has highlighting on candidates depend on types: directory has a color, plain file has a color, executable has a color, shell script has a color.
- Depends on what file type your highlighting candidate is, Helm opens it appropriately. For example, if you RET on a directory, Helm opens dired; if you RET on a file, Helm opens that file. You can also customize the application to open the files. Stock find-file at least can open directory; Ido simply can't.
- You can open multiple files with helm-find-files by marking with C-SPC and press RET. If you want to everything at current directory, you can use M-a to mark all then RET. You can even use wildcard expression like stock find-file
- Helm has a list of actions to apply on your files: checksum file, open file externally, switch to eshell, grep, diff...
- Helm is compatible with both Linux and Windows path. Ido can't; you have to drop into stock find-file.

Vào 23:49:00 UTC+7 Thứ hai, ngày 01 tháng chín năm 2014, York Zhao đã viết:
> I've been using Helm for many years, and it has been a fundamental part of my
> 
> Emacs system. However, I also don't like `helm-find-file', and I agree ido is
> 
> much better in this. By the way, in `helm-find-file', you may want to try using
> 
> the left arrow to go to the parent directory, not as good as in ido but still
> 
> usable. Having said that, I think other than "find file", helm is great in
> 
> anything else.

Re: A package in a league of its own: Helm

[Nikolai Weibull]

On Mon, Sep 1, 2014 at 6:59 PM, Tu, Do <solidius4747@gmail.com> wrote:

I seem to prefer ido for exactly the opposite reasons:

> I think helm-find-files is much better than stock ido-find-file or even ido-find-file because:
>
> - It has fuzzy matching by default. You have to install flx to get fuzzy matching in ido.

Ido comes with Emacs, which is a big plus.  Flx can be installed from
marmalade repo.

> - Some people find that Ido horizontal listing is messy, so they create `ido-vertical-mode` for cleaner looking. With Helm, you get this by default with its interface. If you worry the Helm buffer is a bit big, you can always customize its size.

Configuring ido for vertical output requires one line of code:

(setq ido-decorations (quote ("\n" "" "\n" "\n…" "[" "]" " [No match]"
" [Matched]" " [Not readable]" " [Too big]" " [Confirm]")))

> - It has highlighting on candidates depend on types: directory has a color, plain file has a color, executable has a color, shell script has a color.

I don’t select what file I want to open based on what color it has.
If I know what I’m looking for, I don’t need visual aides to find it.
If I don’t know what I’m looking for, I’ll open Dired.

> - Depends on what file type your highlighting candidate is, Helm opens it appropriately. For example, if you RET on a directory, Helm opens dired; if you RET on a file, Helm opens that file. You can also customize the application to open the files. Stock find-file at least can open directory; Ido simply can't.

C-d in Ido opens the currently selected directory.

> - You can open multiple files with helm-find-files by marking with C-SPC and press RET. If you want to everything at current directory, you can use M-a to mark all then RET. You can even use wildcard expression like stock find-file

If I want to work on multiple files at once, Dired does that for me.

> - Helm has a list of actions to apply on your files: checksum file, open file externally, switch to eshell, grep, diff...

Again, Dired helps me out here.

> - Helm is compatible with both Linux and Windows path. Ido can't; you have to drop into stock find-file.

I’m not sure if this is actually true, but you can always use slash as
a path separator on Windows if Ido can’t handle backslash (which I
wouldn’t hold against it).

My overall feeling when I looked at Helm when this thread appeared was
that there’s already packages that do what Helm does that come with
Emacs: Dired, Ibuffer, and Ido.  Sure, Helm can interface with
Delicious, my web browser, and so on, and if that’s something you want
to do, then Helm is great, but for me, Helm is trying to sell me stuff
that I simply don’t need or want.

Re: A package in a league of its own: Helm

[Óscar Fuentes]

"Tu, Do" <solidius4747@gmail.com> writes:

Some corrections follow.

> - It has fuzzy matching by default. You have to install flx to get
> fuzzy matching in ido.

ido has fuzzy matching (and regexp matching) built-in. IIRC, you can
switch to any of the match algorithms on the fly. flx is an external
package witn a plug-in for ido that does fuzzy matching on steroids.

> - Depends on what file type your highlighting candidate is, Helm opens
> it appropriately. For example, if you RET on a directory, Helm opens
> dired; if you RET on a file, Helm opens that file. You can also
> customize the application to open the files. Stock find-file at least
> can open directory; Ido simply can't.

With ido's find-file you can press C-d to start dired any time. You can
also kill a file.

> - Helm is compatible with both Linux and Windows path. Ido can't; you
> have to drop into stock find-file.

That's not correct. Ido works fine on Windows.

Ido is not as rich as Helm by a long shot, but it is not as poor as you
seem to think either.

In my opinion, one fundamental difference among ido and helm is that ido
is a component for doing one task (being a replacement for Emacs'
completing system, with a few context-dependent extra features like
killing a file while on find-file, etc.) while helm is a replacement of
a large chunk of Emacs' non-text-editing UI. Is like comparing a shovel
with a tractor.

Re: A package in a league of its own: Helm

[York Zhao]

I think my biggest problem with `helm-find-file' is it's "auto-expansion", which
is really annoying. Most of the time I don't want Helm to automatically expand
the file or directory for me because Helm's expansion was always wrong. For
example, I press C-x C-f and I want to open the file "notes/foo.org", but as
soon as I typed note, Helm expand to notes/e which is obviously wrong, and I
always have to type backspace to delete the letter `e', and then type foo.org.
The reason for this is that Helm expanded "not", rather than "note" to "notes/",
and in order to get right I have to type "not" and stop, waiting for Helm to
expand to "note/" before keep typing. But the problem is that you don't know
where to stop typing and wait for Helm. What I want is that Helm do not
automatically expand for me. Instead, let me choose a candidate. Maybe this
behavior can be configured, but I never got the time to research on this yet.

On Mon, Sep 1, 2014 at 12:59 PM, Tu, Do <solidius4747@gmail.com> wrote:
> I think helm-find-files is much better than stock ido-find-file or even ido-find-file because:
>
> - It has fuzzy matching by default. You have to install flx to get fuzzy matching in ido.
> - Some people find that Ido horizontal listing is messy, so they create `ido-vertical-mode` for cleaner looking. With Helm, you get this by default with its interface. If you worry the Helm buffer is a bit big, you can always customize its size.
> - It has highlighting on candidates depend on types: directory has a color, plain file has a color, executable has a color, shell script has a color.
> - Depends on what file type your highlighting candidate is, Helm opens it appropriately. For example, if you RET on a directory, Helm opens dired; if you RET on a file, Helm opens that file. You can also customize the application to open the files. Stock find-file at least can open directory; Ido simply can't.
> - You can open multiple files with helm-find-files by marking with C-SPC and press RET. If you want to everything at current directory, you can use M-a to mark all then RET. You can even use wildcard expression like stock find-file
> - Helm has a list of actions to apply on your files: checksum file, open file externally, switch to eshell, grep, diff...
> - Helm is compatible with both Linux and Windows path. Ido can't; you have to drop into stock find-file.
>
> Vào 23:49:00 UTC+7 Thứ hai, ngày 01 tháng chín năm 2014, York Zhao đã viết:
>> I've been using Helm for many years, and it has been a fundamental part of my
>>
>> Emacs system. However, I also don't like `helm-find-file', and I agree ido is
>>
>> much better in this. By the way, in `helm-find-file', you may want to try using
>>
>> the left arrow to go to the parent directory, not as good as in ido but still
>>
>> usable. Having said that, I think other than "find file", helm is great in
>>
>> anything else.

Re: A package in a league of its own: Helm

[Michael Heerdegen]

York Zhao <gtdplatform@gmail.com> writes:

>  What I want is that Helm do not automatically expand for me. Instead,
> let me choose a candidate. Maybe this behavior can be configured, but
> I never got the time to research on this yet.

`helm-ff-auto-update-initial-value'.  The default behavior has been
changed in the meantime to do what you want (some months ago), because
it had been annoying to lots of people.

Michael.

Re: A package in a league of its own: Helm

[York Zhao]

Hi Michael,

Thanks for reminding me. I actually knew this but have forgotten it. I just
tried it, but didn't like having to press C-z to enter the directory. So I
changed it back to `t'. Maybe I will try longer, and slow down my typing to see
if I can get used to the auto expansion.


On Mon, Sep 1, 2014 at 4:37 PM, Michael Heerdegen
<michael_heerdegen@web.de> wrote:
> York Zhao <gtdplatform@gmail.com> writes:
>
>>  What I want is that Helm do not automatically expand for me. Instead,
>> let me choose a candidate. Maybe this behavior can be configured, but
>> I never got the time to research on this yet.
>
> `helm-ff-auto-update-initial-value'.  The default behavior has been
> changed in the meantime to do what you want (some months ago), because
> it had been annoying to lots of people.
>
> Michael.
>
>

Re: A package in a league of its own: Helm

[Eric Abrahamsen]

York Zhao <gtdplatform@gmail.com> writes:

> Hi Michael,
>
> Thanks for reminding me. I actually knew this but have forgotten it. I just
> tried it, but didn't like having to press C-z to enter the directory. So I
> changed it back to `t'. Maybe I will try longer, and slow down my typing to see
> if I can get used to the auto expansion.

Check Tu Do's explanation above for making this easier to use. I
think lots of people find C-z awkward to use, and swap TAB and C-z:

(define-key helm-map (kbd "<tab>") 'helm-execute-persistent-action)
(define-key helm-map (kbd "C-z") 'helm-select-action)

That fixed my annoyances with helm-find-files.

Re: A package in a league of its own: Helm

[York Zhao]

> Check Tu Do's explanation above for making this easier to use. I
> think lots of people find C-z awkward to use, and swap TAB and C-z:
>
> (define-key helm-map (kbd "<tab>") 'helm-execute-persistent-action)
> (define-key helm-map (kbd "C-z") 'helm-select-action)
>
> That fixed my annoyances with helm-find-files.

I was aware of his suggestion of swapping C-z and TAB, but I'm still not sure
whether I want to do that because I feel like I'm using TAB a lot too. Maybe, I
will give it a go anyway to see how it works for me.

Re: A package in a league of its own: Helm

[Tak Kunihiro]

You can reassign <tab> only during `helm-find-file'.  The
`helm-find-file' almost looks like Dired and I assign "^" for going
up.  Minor side effect is you cannot type in "^" without using C-q.

Sometimes you want to hit <tab> for `helm-selection-action'; however,
you chose not to happen.  Now look for substitute for <tab>.
Something not <tab> can be "C-z", "C-<tab>", and "<SPC>.


(define-key helm-find-files-map (kbd "<tab>")    'helm-execute-persistent-action)
(define-key helm-find-files-map (kbd "C-<tab>")  'helm-select-action)
(define-key helm-find-files-map (kbd "C-z")      'helm-select-action)
(define-key helm-find-files-map (kbd "<SPC>")    'helm-select-action)
(define-key helm-find-files-map (kbd "<return>") 'helm-confirm-and-exit-minibuffer)
(define-key helm-find-files-map (kbd "^")        'helm-find-files-up-one-level)

Re: A package in a league of its own: Helm

[Tu, Do]

Vào 00:25:51 UTC+7 Thứ ba, ngày 02 tháng chín năm 2014, Nikolai Weibull đã viết:
> On Mon, Sep 1, 2014 at 6:59 PM, Tu, Do <solidius4747@gmail.com> wrote:
> 
> 
> 
> I seem to prefer ido for exactly the opposite reasons:
> 
> 
> 
> > I think helm-find-files is much better than stock ido-find-file or even ido-find-file because:
> 
> >
> 
> > - It has fuzzy matching by default. You have to install flx to get fuzzy matching in ido.
> 
> 
> 
> Ido comes with Emacs, which is a big plus.  Flx can be installed from
> 
> marmalade repo.

Stock Ido is a bit better than stock find-file but not that much. At least with stock find-file, you can open a directory or a file. With Ido, you have to switch. You also have to improve Ido with packages.

> > - Some people find that Ido horizontal listing is messy, so they create `ido-vertical-mode` for cleaner looking. With Helm, you get this by default with its interface. If you worry the Helm buffer is a bit big, you can always customize its size.


> Configuring ido for vertical output requires one line of code:
> 
> 
> 
> (setq ido-decorations (quote ("\n" "" "\n" "\n…" "[" "]" " [No match]"
> 
> " [Matched]" " [Not readable]" " [Too big]" " [Confirm]")))

Someone already did that so I just used the package. The package also binds some more key for more convenient such as C-n/C-p and arrow keys. You also get a pointer point to the candidate you are going to select.


> 
> > - It has highlighting on candidates depend on types: directory has a color, plain file has a color, executable has a color, shell script has a color.
> 
> 
> 
> I don’t select what file I want to open based on what color it has.
> 
> If I know what I’m looking for, I don’t need visual aides to find it.
> 
> If I don’t know what I’m looking for, I’ll open Dired.

If you think so, you should try turning off all colors in Dired and see the difference. I don't select files based on what colors have, but it quickly helps to filter unrelated items.

> 
> > - Depends on what file type your highlighting candidate is, Helm opens it appropriately. For example, if you RET on a directory, Helm opens dired; if you RET on a file, Helm opens that file. You can also customize the application to open the files. Stock find-file at least can open directory; Ido simply can't.
> 
> 
> 
> C-d in Ido opens the currently selected directory.

Why should I remember another key binding when it can be done more convenient? Even stock find-file can open file or directory depend on the context.

> 
> > - You can open multiple files with helm-find-files by marking with C-SPC and press RET. If you want to everything at current directory, you can use M-a to mark all then RET. You can even use wildcard expression like stock find-file
> 
> 
> 
> If I want to work on multiple files at once, Dired does that for me.

Yes, but you needs extra steps, when you can do it right in your file browsing section. And what if you don't want to open a Dired buffers, but just the files?

> 
> > - Helm has a list of actions to apply on your files: checksum file, open file externally, switch to eshell, grep, diff...
> 
> 
> 
> Again, Dired helps me out here.

Again, you can make it more convenient. Like, you browse to a file and you want to diff/patch to another file. You don't have to go to another immediate step, that is Dired.

Grep in Helm is interactive, unlike the stock grep/rgrep. Demo: http://tuhdo.github.io/static/live_grep.gif

> 
> > - Helm is compatible with both Linux and Windows path. Ido can't; you have to drop into stock find-file.
> 
> 
> 
> I’m not sure if this is actually true, but you can always use slash as
> 
> a path separator on Windows if Ido can’t handle backslash (which I
> 
> wouldn’t hold against it).

But if you paste Windows path from somewhere, would it work? You have to drop back into stock find-file.

> 
> My overall feeling when I looked at Helm when this thread appeared was
> 
> that there’s already packages that do what Helm does that come with
> 
> Emacs: Dired, Ibuffer, and Ido.  Sure, Helm can interface with
> 
> Delicious, my web browser, and so on, and if that’s something you want
> 
> to do, then Helm is great, but for me, Helm is trying to sell me stuff
> 
> that I simply don’t need or want.

No package does any of this:

- Live grep: http://tuhdo.github.io/static/live_grep.gif
- A live outline tree for jumping to function/variable in current file: 

+ Demo 1: http://tuhdo.github.io/static/part3/helm-semantic-or-imenu.gif
+ Demo 2: https://cloud.githubusercontent.com/assets/4818719/4102208/cda8f392-311e-11e4-9c83-e68df38ef68e.gif

- Show local/global mark ring with nice highlighting of major modes: http://tuhdo.github.io/static/part3/helm-all-mark-rings.gif

- Interactively select color and faces: http://tuhdo.github.io/static/part3/helm-color.gif

- Interactive Eshell history, certainly superior to the stock C-c C-l: http://tuhdo.github.io/static/part3/helm-eshell-history.gif . I store a large amount of eshell/shell history, so I want a quick way to narrow down.

helm-find-files can even find file at point. That is, you don't need to remember ffap as well. If you write Emacs lisp, move point over the required file and execute helm-find-files, it will prompt the file location and you simply RET to enter. All in once nice package.

Re: A package in a league of its own: Helm

[Phillip Lord]

"Tu, Do" <solidius4747@gmail.com> writes:
>> Ido comes with Emacs, which is a big plus.  Flx can be installed from
>> 
>> marmalade repo.
>
> Stock Ido is a bit better than stock find-file but not that much. At least
> with stock find-file, you can open a directory or a file. With Ido, you have
> to switch. You also have to improve Ido with packages.


No, it's really a lot better. You can open a dir or file with ido
(agreed, opening a dir is not an obvious keypress). You can tab down
large directories structures very quickly. ido remebers where you have
been so offers good completions often. You can go up whole directories,
short-cut to "~" and "/". And given a file name you can auto-search.

The only problem with ido is that I miss it when I am not using Emacs
(and for somethings when I am using Emacs). I am interested in helm in
case it is better than ido, but ido is very good.

Phil

Re: A package in a league of its own: Helm

[Tu, Do]

@Ernesto I'm glad you find it helpful. I hope you enjoy Helm :)

@Phil

You should follow the configuration in my guide and swap TAB and C-z. Then, you can press TAB for entering directory. C-l is used to go back to parent directory, it requires two key pressed but it is closer to the home row. I don't think it's much slower. I find it actually faster. If you want to search for any file in your project, you have to use Projectile: https://github.com/bbatsov/projectile

If you don't use Projectile, Ido won't be able to any file in your directory either.

Vào 23:01:22 UTC+7 Thứ hai, ngày 01 tháng chín năm 2014, Phil Lord đã viết:
> First, thanks for the tutorial. I've tried helm (and anything) several
> 
> times, but never got on with it as I have found the experience too
> 
> confusing. I've always reverted to ido. I like the idea of helm because
> 
> it is more pervasive than ido and can do several things at once. I
> 
> dislike the practice of helm because too many things happen at once (and
> 
> the wiki is incomprehensible).
> 
> 
> 
> The thing that I am stuck on at the moment, is file navigation. With
> 
> ido.el, I use [tab] or [del] to move up or down directories (and carry
> 
> on selecting). With helm I have to use C-l C-j which I find much slower
> 
> because of the double keypress and because C-k is in the middle.
> 
> 
> 
> I don't get the behaviour you are talking about with helm. I get a
> 
> single directory at once, and I have to navigate through it to get to
> 
> the files I want.
> 
> 
> 
> Clearly I doing something wrong!
> 
> 
> 
> Phil
> 
> 
> 
> 
> 
> 
> 
> <solidius4747@gmail.com> writes:
> 
> > Consider this path: arch/x86/boot/main.c
> 
> >
> 
> > Can you type the file name first: "main.c", then add "x86" to get the correct
> 
> > file above? I'm pretty sure ido+flx can't do that, but maybe I'm missing
> 
> > something.
> 
> >
> 
> > With Helm, you can simply specify "mai x86" and it narrows to 3 candidates
> 
> > with the above path at the top. The file is in Linux kernel source.
> 
> >
> 
> > Maybe you misunderstood my statement about precise remembering project
> 
> > structure. What I meant was you have to remember the correct path ordering,
> 
> > and that requires you to be familiar with the directory structure. Whlie in
> 
> > Helm, I'm completely new to a directory and simply know nothing about
> 
> > directory structure. With Helm, I can start pop up questions like "is there a
> 
> > main.c that is relate to x86 arch?" and so on.
> 
> >
> 
> >
> 
> 
> 
> -- 
> 
> Phillip Lord,                           Phone: +44 (0) 191 222 7827
> 
> Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
> 
> School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
> 
> Room 914 Claremont Tower,               skype: russet_apples
> 
> Newcastle University,                   twitter: phillord
> 
> NE1 7RU

Re: A package in a league of its own: Helm

[Phillip Lord]

I could rebind helm to make it use tab and delete like ido, although I
think it would still not be as nice as ido. Say I do find-file in a
directory, then select src, then uk, then ac, then ncl (as in a java
project), in ido I go C-xC-f s [rtn][rtn][rtn][rtn] because ido offers
"uk" and the others as the first completion. Helm offers "." and ".." as
the first two, so I have to do C-xCf s
[right][down][down][right][down][down][right]. Or I have to hit the
first key of "uk", then "ac" -- all of which requires thinking about.

I've been using projectile, but with ido -- this is what is giving you
the completion you show?

Well, I am writing. Across the top of the helm-find-file session, my
buffer says:

C-j: Hit1 Expand Candidate, Hit2 or (C-u) Find file
find-file (`C-l': Go up one level)

What does "Hit1" and "Hit2" mean?

Phil




"Tu, Do" <solidius4747@gmail.com> writes:

> @Ernesto I'm glad you find it helpful. I hope you enjoy Helm :)
>
> @Phil
>
> You should follow the configuration in my guide and swap TAB and C-z. Then,
> you can press TAB for entering directory. C-l is used to go back to parent
> directory, it requires two key pressed but it is closer to the home row. I
> don't think it's much slower. I find it actually faster. If you want to search
> for any file in your project, you have to use Projectile:
> https://github.com/bbatsov/projectile
>
> If you don't use Projectile, Ido won't be able to any file in your directory either.
>
> Vào 23:01:22 UTC+7 Thứ hai, ngày 01 tháng chín năm 2014, Phil Lord đã viết:
>> First, thanks for the tutorial. I've tried helm (and anything) several
>> 
>> times, but never got on with it as I have found the experience too
>> 
>> confusing. I've always reverted to ido. I like the idea of helm because
>> 
>> it is more pervasive than ido and can do several things at once. I
>> 
>> dislike the practice of helm because too many things happen at once (and
>> 
>> the wiki is incomprehensible).
>> 
>> 
>> 
>> The thing that I am stuck on at the moment, is file navigation. With
>> 
>> ido.el, I use [tab] or [del] to move up or down directories (and carry
>> 
>> on selecting). With helm I have to use C-l C-j which I find much slower
>> 
>> because of the double keypress and because C-k is in the middle.
>> 
>> 
>> 
>> I don't get the behaviour you are talking about with helm. I get a
>> 
>> single directory at once, and I have to navigate through it to get to
>> 
>> the files I want.
>> 
>> 
>> 
>> Clearly I doing something wrong!
>> 
>> 
>> 
>> Phil
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> <solidius4747@gmail.com> writes:
>> 
>> > Consider this path: arch/x86/boot/main.c
>> 
>> >
>> 
>> > Can you type the file name first: "main.c", then add "x86" to get the correct
>> 
>> > file above? I'm pretty sure ido+flx can't do that, but maybe I'm missing
>> 
>> > something.
>> 
>> >
>> 
>> > With Helm, you can simply specify "mai x86" and it narrows to 3 candidates
>> 
>> > with the above path at the top. The file is in Linux kernel source.
>> 
>> >
>> 
>> > Maybe you misunderstood my statement about precise remembering project
>> 
>> > structure. What I meant was you have to remember the correct path ordering,
>> 
>> > and that requires you to be familiar with the directory structure. Whlie in
>> 
>> > Helm, I'm completely new to a directory and simply know nothing about
>> 
>> > directory structure. With Helm, I can start pop up questions like "is there a
>> 
>> > main.c that is relate to x86 arch?" and so on.
>> 
>> >
>> 
>> >
>> 
>> 
>> 
>> -- 
>> 
>> Phillip Lord,                           Phone: +44 (0) 191 222 7827
>> 
>> Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
>> 
>> School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
>> 
>> Room 914 Claremont Tower,               skype: russet_apples
>> 
>> Newcastle University,                   twitter: phillord
>> 
>> NE1 7RU
>
>
>

-- 
Phillip Lord,                           Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,               skype: russet_apples
Newcastle University,                   twitter: phillord
NE1 7RU                                 

Re: A package in a league of its own: Helm

[York Zhao]

> I've been using projectile, but with ido -- this is what is giving you the
> completion you show?

helm-find-file is actually the only thing I can't get used to (yet) in Helm.
Other than that, Helm is great. Especially if you use projectile. When I started
to use projectile, I gave myself a chance to see how ido goes, and I used
projectile with ido for a while. But I finally decided that ido was not what I
want while using projectile. Therefor, I've improved helm-projectile, and if you
pull the latest projectile you will find that the helm interface has been
improved. In short, in order to use projectile with Helm, you can now type C-c
ph (`helm-projectile'), then you can type something to select your project. Now,
if you press ENTER you will be provided to select the file in your project, with
Helm. However, you can also type C-d to open Dired for your project, M-g to goto
VC or Magit and M-e to open Eshell. These four actions are what I've been using
a lot, but I'm sure we can add much more useful actions. So, give
`helm-projectile' (bound to C-c ph) a go to see how you like it.

York

Re: A package in a league of its own: Helm

[Phillip Lord]

York Zhao <gtdplatform@gmail.com> writes:
>> I've been using projectile, but with ido -- this is what is giving you the
>> completion you show?
>
> helm-find-file is actually the only thing I can't get used to (yet) in Helm.
> Other than that, Helm is great. Especially if you use projectile. When I started
> to use projectile, I gave myself a chance to see how ido goes, and I used
> projectile with ido for a while. But I finally decided that ido was not what I
> want while using projectile. Therefor, I've improved helm-projectile, and if you
> pull the latest projectile you will find that the helm interface has been
> improved. In short, in order to use projectile with Helm, you can now type C-c
> ph (`helm-projectile'), then you can type something to select your project. Now,
> if you press ENTER you will be provided to select the file in your project, with
> Helm. However, you can also type C-d to open Dired for your project, M-g to goto
> VC or Magit and M-e to open Eshell. These four actions are what I've been using
> a lot, but I'm sure we can add much more useful actions. So, give
> `helm-projectile' (bound to C-c ph) a go to see how you like it.


But you still have to use helm-find-files to get to the project in the
first place? I tend to work on a lot of projects (and stuff not in
projects) during a single day.

Phil

Re: A package in a league of its own: Helm

[York Zhao]

> But you still have to use helm-find-files to get to the project in the
> first place? I tend to work on a lot of projects (and stuff not in
> projects) during a single day.
>
> Phil

No, you don't use helm-find-files to get to your project, you use
helm-projectile (bound to C-c ph) to get to your project. It has nothing to do
with helm-find-files. Because I don't like helm-find-files, I always try not to
use it, whenever possible.

York

Re: A package in a league of its own: Helm

[Phillip Lord]

York Zhao <gtdplatform@gmail.com> writes:

>> But you still have to use helm-find-files to get to the project in the
>> first place? I tend to work on a lot of projects (and stuff not in
>> projects) during a single day.
>>
>> Phil
>
> No, you don't use helm-find-files to get to your project, you use
> helm-projectile (bound to C-c ph) to get to your project. It has nothing to do
> with helm-find-files. Because I don't like helm-find-files, I always try not to
> use it, whenever possible.

That only works when you are already in a project. Feels like a
bootstrap problem to me!

Phil

Re: A package in a league of its own: Helm

[Tu, Do]

Vào 16:58:49 UTC+7 Thứ tư, ngày 03 tháng chín năm 2014, Phil Lord đã viết:
> York Zhao <gtdplatform@gmail.com> writes:
> 
> 
> 
> >> But you still have to use helm-find-files to get to the project in the
> 
> >> first place? I tend to work on a lot of projects (and stuff not in
> 
> >> projects) during a single day.
> 
> >>
> 
> >> Phil
> 
> >
> 
> > No, you don't use helm-find-files to get to your project, you use
> 
> > helm-projectile (bound to C-c ph) to get to your project. It has nothing to do
> 
> > with helm-find-files. Because I don't like helm-find-files, I always try not to
> 
> > use it, whenever possible.
> 
> 
> 
> That only works when you are already in a project. Feels like a
> 
> bootstrap problem to me!
> 
> 
> 
> Phil

You visit a project once and Projectile will remember. But it's true that you still need helm-find-files or other methods for entering project directories. Or, you can run "git init" at your home directory and jump to any project directories.

Re: A package in a league of its own: Helm

[Tu, Do]

Vào 00:03:51 UTC+7 Thứ tư, ngày 03 tháng chín năm 2014, York Zhao đã viết:
> > But you still have to use helm-find-files to get to the project in the
> 
> > first place? I tend to work on a lot of projects (and stuff not in
> 
> > projects) during a single day.
> 
> >
> 
> > Phil
> 
> 
> 
> No, you don't use helm-find-files to get to your project, you use
> 
> helm-projectile (bound to C-c ph) to get to your project. It has nothing to do
> 
> with helm-find-files. Because I don't like helm-find-files, I always try not to
> 
> use it, whenever possible.
> 
> 
> 
> York

In helm-find-files, you can alway invoke helm-ff-do-grep with C-s or C-u C-s for recursive searching. Probably helm-projectile can replace helm-find-files more if it has this feature? I think you can do this by reusing projectile-grep.

Re: A package in a league of its own: Helm

[York Zhao]

> In helm-find-files, you can alway invoke helm-ff-do-grep with C-s or C-u C-s
> for recursive searching. Probably helm-projectile can replace helm-find-files
> more if it has this feature? I think you can do this by reusing
> projectile-grep.

I was aware of the grep in helm-find-files, and I agree it's nice. I'm going to
add grep to helm-projectile and then send a pull request, thank you for the
suggestion. However, I may do it late today or tomorrow, so if you can't wait,
and want to add it now, that would be even better. Just let me know if you want
to do that so I'm not going to worry about it. And I guess eventually we may
want to add helm interface for everything that can be done with
projectile-ido. :)

York

Re: A package in a league of its own: Helm

[Tu]

Thanks for implementing. Worry not, i'm in no rush. Just do it when you are comfortable.

>> In helm-find-files, you can alway invoke helm-ff-do-grep with C-s or C-u C-s
>> for recursive searching. Probably helm-projectile can replace helm-find-files
>> more if it has this feature? I think you can do this by reusing
>> projectile-grep.
> 
> I was aware of the grep in helm-find-files, and I agree it's nice. I'm going to
> add grep to helm-projectile and then send a pull request, thank you for the
> suggestion. However, I may do it late today or tomorrow, so if you can't wait,
> and want to add it now, that would be even better. Just let me know if you want
> to do that so I'm not going to worry about it. And I guess eventually we may
> want to add helm interface for everything that can be done with
> projectile-ido. :)
> 
> York

Re: A package in a league of its own: Helm

[York Zhao]

> Thanks for implementing. Worry not, i'm in no rush. Just do it when you are
> comfortable

OK, I've added the incremental grep in helm-projectile to grep in the selected
projects. It works like a charm, and I think I will love it. I have sent the
pull request to Bozhidar Batsov, so before he merges my changes, you can pull it
from my repo at https://github.com/YorkZ/projectile/tree/helm-switch-project.

York

Re: A package in a league of its own: Helm

[Tu, Do]

On Wednesday, September 3, 2014 7:35:33 AM UTC+7, York Zhao wrote:
> > Thanks for implementing. Worry not, i'm in no rush. Just do it when you are
> 
> > comfortable
> 
> 
> 
> OK, I've added the incremental grep in helm-projectile to grep in the selected
> 
> projects. It works like a charm, and I think I will love it. I have sent the
> 
> pull request to Bozhidar Batsov, so before he merges my changes, you can pull it
> 
> from my repo at https://github.com/YorkZ/projectile/tree/helm-switch-project.
> 
> 
> 
> York

That's a cool addition there. I have another suggestion: it would be better if switching between projects reuses helm-projectile interface instead of going into projectile-find-file with Helm interface. What do you think?

Re: A package in a league of its own: Helm

[Tu, Do]

Vào 20:19:52 UTC+7 Thứ ba, ngày 02 tháng chín năm 2014, Phil Lord đã viết:
> I could rebind helm to make it use tab and delete like ido, although I
> 
> think it would still not be as nice as ido. Say I do find-file in a
> 
> directory, then select src, then uk, then ac, then ncl (as in a java
> 
> project), in ido I go C-xC-f s [rtn][rtn][rtn][rtn] because ido offers
> 
> "uk" and the others as the first completion. Helm offers "." and ".." as
> 
> the first two, so I have to do C-xCf s
> 
> [right][down][down][right][down][down][right]. Or I have to hit the
> 
> first key of "uk", then "ac" -- all of which requires thinking about.
>

For an edge case like that where everything is at the top, then even stock find-file is fast. But then, your current directory contains many files then you may one to look around to see the files in that directory. In that case, Ido cannot do it because you cannot have an actually buffer to scroll up/down to see. In this case, with Ido, you have to drop into Dired, look around and start ido-find-file again.

> I've been using projectile, but with ido -- this is what is giving you
> 
> the completion you show?
> 
> 
> 
> Well, I am writing. Across the top of the helm-find-file session, my
> 
> buffer says:
> 
> 
> 
> C-j: Hit1 Expand Candidate, Hit2 or (C-u) Find file
> 
> find-file (`C-l': Go up one level)
> 
> 
> 
> What does "Hit1" and "Hit2" mean?
> 
> 
> 
> Phil

helm-projectile is really nice but if you want to look at the current directory or navigate around, you should use helm-find-files. C-j means that you proceed to the next level, that is either a file or a directory. Hit 1 means pressing one time. Hit 2 means pressing 2 times; pres you hit C-j twices and if your highlighting is on a file, then the file content is opened up in another buffer. You can also press C-u in helm-find-files; its has the same effect as pressing C-j twice. You can navigate the other buffer with M-<next>/M-<prior>.

Actually, navigating back and forth with C-j/C-l is much faster than <tab> and <delete>/<return> since both of those keys are on the home row.

Re: A package in a league of its own: Helm

[Phillip Lord]

"Tu, Do" <solidius4747@gmail.com> writes:
>> I could rebind helm to make it use tab and delete like ido, although I
>> 
>> think it would still not be as nice as ido. Say I do find-file in a
>> 
>> directory, then select src, then uk, then ac, then ncl (as in a java
>> 
>> project), in ido I go C-xC-f s [rtn][rtn][rtn][rtn] because ido offers
>> 
>> "uk" and the others as the first completion. Helm offers "." and ".." as
>> 
>> the first two, so I have to do C-xCf s
>> 
>> [right][down][down][right][down][down][right]. Or I have to hit the
>> 
>> first key of "uk", then "ac" -- all of which requires thinking about.
>>
>
> For an edge case like that where everything is at the top, then even stock
> find-file is fast. 


This is not an edge case for me. I have a lot of empty directories. In
the ideal world ido or helm would just squash them.


> But then, your current directory contains many files then you may one
> to look around to see the files in that directory. In that case, Ido
> cannot do it because you cannot have an actually buffer to scroll
> up/down to see. In this case, with Ido, you have to drop into Dired,
> look around and start ido-find-file again.


Yes, this is true, if the number of files is large. For small numbers
you can see the options, for large numbers this is truncated.

>> C-j: Hit1 Expand Candidate, Hit2 or (C-u) Find file
>> 
>> find-file (`C-l': Go up one level)
>> 
>> 
>> 
>> What does "Hit1" and "Hit2" mean?
>> 
>> 
>> 
>> Phil
>
> helm-projectile is really nice but if you want to look at the current
> directory or navigate around, you should use helm-find-files. C-j means that
> you proceed to the next level, that is either a file or a directory. Hit 1
> means pressing one time. Hit 2 means pressing 2 times; pres you hit C-j twices
> and if your highlighting is on a file, then the file content is opened up in
> another buffer. You can also press C-u in helm-find-files; its has the same
> effect as pressing C-j twice. You can navigate the other buffer with
> M-<next>/M-<prior>.


Okay, that's a good explanation!



> Actually, navigating back and forth with C-j/C-l is much faster than <tab> and
> <delete>/<return> since both of those keys are on the home row.

Well, we both having the confounding factor that I am used to
del/tab/ret and you are used to C-j/C-l. None the less, I would argue
that single key presses are faster than doubles, especially for
tab/del/retn which everyone uses a lot and are nice and big.

Phil

Re: A package in a league of its own: Helm

[Ernesto Durante]

solidius4747@gmail.com writes:

> I wrote a guide for Helm here: http://tuhdo.github.io/helm-intro.html
>
> Hope it help with your Helm usage if you are new to Helm.

Hi
I enjoy working with helm. It's a great package. I really appreciate
your guide.

Thanks for sharing
Best
Ernesto