Helm behaves different with find-file and dired

[Geoffrey Ferrari]

Hi everyone,

When I use helm with C-x C-f (find-file), the helm buffer automatically selects a candidate file based on my input in the minibuffer. For example, if I find-file and then type ".bas" helm automatically highlights my .bashrc, which I can then open by hitting return.

However, when I'm finding a directory with C-x d (dired), helm behaves differently. If the directory "test" is in the candidate list, then if I type "test" in the minibuffer, the directory is never automatically selected. It's then more difficult to open this file - I have to navigate to this file in the helm buffer and then hit return.

Please could someone help me understand why there is this difference of behaviour and how I can make dired work like find-file? I've tried stepping through the code but helm is complex.

Thanks,

Geoff

[Thierry Volpiatto]

Geoffrey Ferrari <geoffrey...@gmail.com> writes:

> Hi everyone,
>
> When I use helm with C-x C-f (find-file), the helm buffer
> automatically selects a candidate file based on my input in the
> minibuffer. For example, if I find-file and then type ".bas" helm
> automatically highlights my .bashrc, which I can then open by hitting
> return.
>
> However, when I'm finding a directory with C-x d (dired), helm behaves
> differently. If the directory "test" is in the candidate list, then if
> I type "test" in the minibuffer, the directory is never automatically
> selected.

This is not reproductible, here the directory is automatically selected
unless there is test1, test2 etc... in you directory.

> It's then more difficult to open this file - I have to navigate to
> this file in the helm buffer and then hit return.
>
> Please could someone help me understand why there is this difference
> of behaviour and how I can make dired work like find-file? I've tried
> stepping through the code but helm is complex.

dired and find-file are helmized by helm-mode with a generic function,
you have better time (as specified in the README and wiki) to use native
helm commands.
IOW you have better time using `helm-find-files` for all tasks related
to files (you can do everything from this single command).

--
Thierry

[Geoffrey Ferrari]

Thanks for your reply Thierry. I made a mistake earlier, and I am
actually using helm-find-files with C-x C-f. I like the behaviour I
get with helm-find-files, but as I noted above, I get different
behaviour with dired. I've confirmed that this happens on a vanilla
emacs installation (started with emacs -q and loading just what I need
to get helm up and running). I don't know what's causing this
difference, so if anyone has any suggestions, please let me know.

I appreciate Thierry's suggestion to just use helm-find-files. But my
question is whether I can make the dired command work differently.

Thanks again,

Geoff

On 3 January 2016 at 10:30, Thierry Volpiatto

> --
> You received this message because you are subscribed to a topic in the Google Groups "emacs-helm" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/emacs-helm/AcwgpxV_M1Y/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to emacs-helm+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Michael Heerdegen]

Geoffrey Ferrari

<geoffrey...@oriel.oxon.org> writes:

> Thanks for your reply Thierry. I made a mistake earlier, and I am
> actually using helm-find-files with C-x C-f. I like the behaviour I
> get with helm-find-files, but as I noted above, I get different
> behaviour with dired. I've confirmed that this happens on a vanilla
> emacs installation (started with emacs -q and loading just what I need
> to get helm up and running). I don't know what's causing this
> difference, so if anyone has any suggestions, please let me know.

Maybe you experience and wonder about the behavior we introduced here:

https://github.com/emacs-helm/helm/issues/910

via `helm-ff-move-to-first-real-candidate'.

This was make the behavior of +, C, etc in dired more consistent with
vanilla Emacs, but for the `dired' command itself, it can feel
unaccustomed.


Michael.

[Thierry Volpiatto]

Geoffrey Ferrari <geoffrey...@oriel.oxon.org> writes:

> Thanks for your reply Thierry. I made a mistake earlier, and I am
> actually using helm-find-files with C-x C-f. I like the behaviour I
> get with helm-find-files, but as I noted above, I get different
> behaviour with dired. I've confirmed that this happens on a vanilla
> emacs installation (started with emacs -q and loading just what I need
> to get helm up and running). I don't know what's causing this
> difference, so if anyone has any suggestions, please let me know.
>
> I appreciate Thierry's suggestion to just use helm-find-files. But my
> question is whether I can make the dired command work differently.

Actually I can't reproduce your problem with dired, perhaps you can make
a recipe with a test directory so that I can reproduce ?

--
Thierry

[Eric Abrahamsen]

Thierry Volpiatto

This has also annoyed me slightly for a while. If I am in a directory
that looks like this:

test/
file.txt
subdir/

If I use `helm-find-files' while in "test", and type "txt", then
"file.txt" is selected and RET opens it.

If I use `dired' in that directory, and typ "dir", the candidates are
narrowed to "subdir", but that candidate is *not* selected, and hitting
RET will give me "no such directory: test/dir". I still need to move the
selection down to the "subdir" line to actually enter it.

E

[Michael Heerdegen]

Eric Abrahamsen <er...@ericabrahamsen.net>
writes:

> If I use `dired' in that directory, and typ "dir", the candidates are
> narrowed to "subdir", but that candidate is *not* selected, and hitting
> RET will give me "no such directory: test/dir". I still need to move the
> selection down to the "subdir" line to actually enter it.

See my message <87d1tih...@web.de>, which explains the reason.
Before that patch, the behavior was even more annoying for all
dired-do-* commands.

I think we can change it. The question is how to determine (instead of
hardcoding a list) which dired command should behave in which way
(i.e. asking for a existing vs. a new file name).

Ideas welcome.


Regards,

Michael.

[Eric Abrahamsen]

Michael Heerdegen <michael_...@web.de>
writes:

I see!

Well, off the top of my head, I'd say plain `dired' should auto-select
existing candidates, and `dired-create-directory' shouldn't.

After that, my personal preference for the various `dired-do-*'
functions would be to assume existing directories (ie auto-select
existing), but I can imagine other people might have different opinions.

Are there complexities I'm not thinking of?

Thanks,
Eric

[Michael Heerdegen]

Eric Abrahamsen <er...@ericabrahamsen.net>
writes:

> Well, off the top of my head, I'd say plain `dired' should auto-select
> existing candidates, and `dired-create-directory' shouldn't.
>
> After that, my personal preference for the various `dired-do-*'
> functions would be to assume existing directories (ie auto-select
> existing), but I can imagine other people might have different opinions.

Should preselection behavior differ for directories and regular files
(because you speak of "directories")?

I guess what you expect can differ for more than one class, think of

just dired
+ in dired
C in dired
S in dired

it's always different whether preselection for directories and regular
files would make sense.

> Are there complexities I'm not thinking of?

I guess we could just exclude "dired" itself for now from the special
treatment and see how it feels. Until now, AFAIK nobody complained
about any command apart from dired itself.


Michael.

[Eric Abrahamsen]

Michael Heerdegen <michael_...@web.de>
writes:

> Eric Abrahamsen <er...@ericabrahamsen.net>
> writes:
>
>> Well, off the top of my head, I'd say plain `dired' should auto-select
>> existing candidates, and `dired-create-directory' shouldn't.
>>
>> After that, my personal preference for the various `dired-do-*'
>> functions would be to assume existing directories (ie auto-select
>> existing), but I can imagine other people might have different opinions.
>
> Should preselection behavior differ for directories and regular files
> (because you speak of "directories")?

I think the real question is -- should it differ for `dired' and
`helm-find-files'. Find files can create files, dired can't create
directories. To me, that indicates that dired should be even *more*
tilted towards preselection than find-files.

> I guess what you expect can differ for more than one class, think of
>
> just dired
> + in dired
> C in dired
> S in dired
>
> it's always different whether preselection for directories and regular
> files would make sense.

Yes, but as I said, I think it makes sense for plain dired and the
dired-do-* commands (ie R, C, S, etc) to preselect, and
dired-create-directory (ie +) to not.

>> Are there complexities I'm not thinking of?
>
> I guess we could just exclude "dired" itself for now from the special
> treatment and see how it feels. Until now, AFAIK nobody complained
> about any command apart from dired itself.

Yup -- I find that everything else works as I expect/want it to, except
for dired.

E

[Thierry Volpiatto]

Eric Abrahamsen <er...@ericabrahamsen.net> writes:

> This has also annoyed me slightly for a while. If I am in a directory
> that looks like this:
>
> test/
> file.txt
> subdir/
>
> If I use `helm-find-files' while in "test", and type "txt", then
> "file.txt" is selected and RET opens it.
>
> If I use `dired' in that directory, and typ "dir", the candidates are
> narrowed to "subdir", but that candidate is *not* selected, and hitting
> RET will give me "no such directory: test/dir". I still need to move the
> selection down to the "subdir" line to actually enter it.

Should be fixed now, but still have the same behavior for other dired
commands.

--
Thierry

[Michael Heerdegen]

Thierry Volpiatto

<thierry....@gmail.com> writes:

> Should be fixed now, but still have the same behavior for other dired
> commands.

Thanks, that's what I intended to do.


Michael.

[Eric Abrahamsen]

Michael Heerdegen <michael_...@web.de>
writes:

> Thierry Volpiatto
> <thierry....@gmail.com> writes:
>
>> Should be fixed now, but still have the same behavior for other dired
>> commands.

Thanks you guys! People are bound to be picky about this sort of stuff
-- it's so fundamental to daily usage. Speaking of which, is there any
way this kind of behavior could be opened up to customization? Then you
wouldn't have to keep fielding these complaints...

[Michael Heerdegen]

Eric Abrahamsen <er...@ericabrahamsen.net>
writes:

> Thanks you guys! People are bound to be picky about this sort of stuff
> -- it's so fundamental to daily usage. Speaking of which, is there any
> way this kind of behavior could be opened up to customization? Then
> you wouldn't have to keep fielding these complaints...

What do you mean by "this kind of"? This case here was quite special.

In general (and especially for Helm) leaving more stuff open to
customization makes the code harder to maintain and will more likely
lead to bugs in some of the O(2^#options) customization cases, so we
(which mainly means Thierry) try to avoid to introduce additional
options if there is no clear benefit. It's better to handle the
complaints most of the time, and add an option if it's really useful.

Hooks are a bit better with respect to this, but a hook would not have
helped here much.


Regards,

Michael.

[Eric Abrahamsen]

Michael Heerdegen <michael_...@web.de>
writes:

By "this kind of" I guess I mostly meant the difference between
pre-selection, and no pre-selection. It just seems like one of those
areas where everyone's going to have slightly different preferences, but
also very *strong* preferences, and it might just be easier to let them
handle it themselves.

Though I certainly appreciate the added coding complexity of making this
a user option! Mostly I was just curious.

E

[Thierry Volpiatto]

Eric Abrahamsen <er...@ericabrahamsen.net> writes:

> By "this kind of" I guess I mostly meant the difference between
> pre-selection, and no pre-selection. It just seems like one of those
> areas where everyone's going to have slightly different preferences, but
> also very *strong* preferences, and it might just be easier to let them
> handle it themselves.
>
> Though I certainly appreciate the added coding complexity of making this
> a user option! Mostly I was just curious.

We generally don't try to be too clever with helmized functions, that is
the emacs vanilla comands helmized by helm-mode.
OTH the native helm commands are generally fully customizable and when
there is some we expect people to use them. I spent a lot of time
developing helm-find-files and I expect people use it instead of basic
helmized commands (I personally don't use dired at all).

--
Thierry

[Eric Abrahamsen]

Thierry Volpiatto

Right, I remember having seen you write elsewhere that Helm can
basically do everything dired does. I believe you, but it's still
frightening to let go of! I do use the native commands elsewhere.

Anyway, thanks for the answers.