unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: "Tu, Do" <solidius4747@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: A package in a league of its own: Helm
Date: Tue, 2 Sep 2014 01:21:38 -0700 (PDT)	[thread overview]
Message-ID: <53756104-40ab-4c80-8112-13f305208be5@googlegroups.com> (raw)
In-Reply-To: <mailman.8046.1409592357.1147.help-gnu-emacs@gnu.org>

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.


  parent reply	other threads:[~2014-09-02  8:21 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-29  4:18 A package in a league of its own: Helm solidius4747
2014-08-29  5:49 ` Guide for package use?(was A package in a league of its own: Helm) Rusi
2014-08-29  6:17   ` solidius4747
2014-08-29 13:36 ` A package in a league of its own: Helm Óscar Fuentes
     [not found] ` <mailman.7830.1409319420.1147.help-gnu-emacs@gnu.org>
2014-08-29 14:03   ` solidius4747
2014-08-29 15:06   ` solidius4747
2014-08-29 16:48     ` Óscar Fuentes
     [not found]     ` <mailman.7852.1409330926.1147.help-gnu-emacs@gnu.org>
2014-08-29 17:08       ` solidius4747
2014-08-29 18:03         ` Óscar Fuentes
     [not found]         ` <mailman.7861.1409335444.1147.help-gnu-emacs@gnu.org>
2014-08-30  1:49           ` solidius4747
2014-08-30  3:33             ` Óscar Fuentes
     [not found]             ` <mailman.7892.1409369651.1147.help-gnu-emacs@gnu.org>
2014-08-30  3:55               ` solidius4747
2014-09-01 16:01         ` Phillip Lord
2014-09-01 16:49           ` York Zhao
2014-09-02 13:06             ` Phillip Lord
     [not found]           ` <mailman.8044.1409590146.1147.help-gnu-emacs@gnu.org>
2014-09-01 16:59             ` Tu, Do
2014-09-01 17:25               ` Nikolai Weibull
2014-09-01 17:28               ` Óscar Fuentes
2014-09-01 17:40               ` York Zhao
2014-09-01 20:37                 ` Michael Heerdegen
2014-09-02  0:27                   ` York Zhao
2014-09-02  1:40                     ` Eric Abrahamsen
2014-09-02  1:56                       ` York Zhao
2014-09-02 23:15                         ` Tak Kunihiro
     [not found]               ` <mailman.8046.1409592357.1147.help-gnu-emacs@gnu.org>
2014-09-02  8:21                 ` Tu, Do [this message]
2014-09-02 13:27                   ` Phillip Lord
     [not found]         ` <mailman.8039.1409587302.1147.help-gnu-emacs@gnu.org>
2014-09-01 16:43           ` Tu, Do
2014-09-02 13:19             ` Phillip Lord
2014-09-02 14:13               ` York Zhao
2014-09-02 14:20                 ` Phillip Lord
2014-09-02 17:03                   ` York Zhao
2014-09-03  9:58                     ` Phillip Lord
     [not found]                     ` <mailman.8183.1409738348.1147.help-gnu-emacs@gnu.org>
2014-09-03 10:19                       ` Tu, Do
     [not found]                   ` <mailman.8134.1409677438.1147.help-gnu-emacs@gnu.org>
2014-09-02 17:11                     ` Tu, Do
2014-09-02 17:32                       ` York Zhao
2014-09-02 18:15                         ` Tu
2014-09-03  0:35                           ` York Zhao
     [not found]                           ` <mailman.8166.1409704538.1147.help-gnu-emacs@gnu.org>
2014-09-03  3:50                             ` Tu, Do
     [not found]             ` <mailman.8106.1409664004.1147.help-gnu-emacs@gnu.org>
2014-09-02 14:32               ` Tu, Do
2014-09-03 10:43                 ` Phillip Lord
2014-08-31  9:09 ` Ernesto Durante

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53756104-40ab-4c80-8112-13f305208be5@googlegroups.com \
    --to=solidius4747@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).