Disable helm-completion for creating directory in Dired

[Plypy]

When I want to use + to create a new directory in dired mode, the completion is very annoying.

[thierryvolpiatto]

Weihua Cheung notifications@github.com writes:

When I want to use + to create a new directory in dired mode, the
completion is very annoying.

I don't see why the completion is annoying, specially if you want to
create a nested directory in one of the subdirs listed in your dired
buffer, but well, if you really don't want this, use:

(add-to-list 'helm-completing-read-handlers-alist
'(dired-create-directory . nil))

or even better use the customize interface, to customize
`helm-completing-read-handlers-alist'.

Note: If you use helm-find-files you can create directories in a
much better way than with dired, among other things.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[Plypy]

I don't see why the completion is annoying, specially if you want to
create a nested directory in one of the subdirs listed in your dired
buffer

Thanks for your fast response.

The completion is indeed useful for subdirectory creation. However, supposing I've already haven a directory named apple, it will be impossible for me to create another one named app in dired. In general, you can't create a new directory whose name is by accidentally some sub-sequences of other existing files/directories.

[thierryvolpiatto]

Weihua Cheung notifications@github.com writes:

I don't see why the completion is annoying, specially if you want to
create a nested directory in one of the subdirs listed in your dired
buffer

The completion is indeed useful for subdirectory creation. However,
supposing I've already haven a directory named apple, it will be
impossible for me to create another one named app in dired.

Huh! Why? of course you can create a directory named "app"!

In general, you can't create a new directory whose name is by
accidentally some sub-sequences of other existing files/directories.

Yes you can!

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[thierryvolpiatto]

After hitting "+" from dired, I guess that as soon you enter "app" helm is completing to "apple" , right ?
So at this time (or before entering "app") hit C-<backspace> now you can write "app" without helm completing to "apple".

[thierryvolpiatto]

From helm-find-files you can do the same, and after "app" add a "/" and hit RET.
If you don't disable auto update with C-<backspace>, you can hit C-b as many time as needed to reach the end of "app", add a "/" C-k and RET.

[thierryvolpiatto]

Note also that auto update is controlled by helm-ff-auto-update-initial-value which is, I guess, non--nil in your configuration, which is not bad, I use it too.
Just to be sure you know you can disable it if you don't like it.

[michael-heerdegen]

This is not only about auto updating. When hitting + in dired, with helm completion, helm always preselects the first (existing) completion candidate, which is nonsense when you need to specify a new dir name. You need to explicitly select the first (uncompleted) candidate, which is annoying.

This problem more or less also applies to S, Y, C, R etc. I do the following in my init file:

   (cl-callf2 nconc
       (cl-loop for s being the symbols
        if (and (string-match-p "dired" (symbol-name s))
            (commandp s))
        collect (list s))
       helm-completing-read-handlers-alist)

[thierryvolpiatto]

Michael Heerdegen notifications@github.com writes:

This is not only about auto updating. When hitting + in dired, with
helm completion, helm always preselects the first (existing)
completion candidate, which is nonsense when you need to specify a new
dir name. You need to explicitly select the first (uncompleted)
candidate, which is annoying.

Sorry but I don't see this here, probably due to something in your own
settings.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[tuhdo]

@thierryvolpiatto if you type a name that has common prefix with other items in the directory, Helm always pre-selects the second line (the first line is for creating new item). Only when we enter non-existing item, our choice is selected because there's nothing else. I think for commands that creates things, Helm should prioritize the first item. That is, the line with [?] before it.

[thierryvolpiatto]

Tu Do notifications@github.com writes:

@thierryvolpiatto if you type a name that has common prefix with other
items in the directory, Helm always pre-selects the second line (the
first line is for creating new item).

Really a minor annoyance, and in most cases it is an advantage.
(This feature was not existing before and I have implemented it after
requests from many users).
And for the case of directory creation, adding a final slash fix the problem.

Only when we enter non-existing item, our choice is selected because
there's nothing else. I think for commands that creates things,

You can't know in advance the intention of user.

Helm should prioritize the first item. That is, the line with [?]
before it.

I think the current behavior is more than reasonable.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[michael-heerdegen]

It is like helm-M-x: it's not problematic per se, but breaking with keystrokes practiced for thousands of times.

[thierryvolpiatto]

Tu Do notifications@github.com writes:

@thierryvolpiatto if you type a name that has common prefix with other
items in the directory, Helm always pre-selects the second line (the
first line is for creating new item). Only when we enter non-existing
item, our choice is selected because there's nothing else. I think for
commands that creates things, Helm should prioritize the first
item. That is, the line with [?] before it.

I have finally fixed this one.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[michael-heerdegen]

Thanks, I've commented out my "fix" in my init file to test your change.

[michael-heerdegen]

Mmh, it seems the problem the problem is back, the behavior is as it was before.

[michael-heerdegen]

Short version so that you don't have to re-read everything: you made the dired functions (like rename, copy) not prefer the first match as input (which makes not much sense for e.g. adding a new directory or renaming) in the helminized version but to default to the plain user input. That worked quite a time, but it stopped working some while ago (maybe two months or so).

The reason why I reopen it now is that there was a question about the issue in gnu.emacs.help.

[thierryvolpiatto]

Michael Heerdegen notifications@github.com writes:

Short version so that you don't have to re-read everything: you made
the dired functions (like rename, copy) not prefer the first match as
input (which makes not much sense for e.g. adding a new directory or
renaming) in the helminized version but to default to the plain user
input. That worked quite a time, but it stopped working some while ago
(maybe two months or so).

Thanks.

This start happening 3 months ago at e1cd1ee when fixing #1099.

Will have a look soon.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[michael-heerdegen]

Looks good. Though, in a few cases, fuzzy matching still seems to make trouble.
For example, I have a file named "Rathenow" in a dir, and when I enter "rthn", this candidate is still selected. If I enter "rathenow" (the exact string, or a substring), or any random string, it behaves as we want after your fix.

Anyway, thanks for your work so far.

[michael-heerdegen]

Correction of my example: until "rathe", the "Rathenow" file line is not selected, but hitting the next letter "n" then selects it. But this is just a random example, you probably already know where to dig.

[michael-heerdegen]

Ok, so far, it seems to be completely fixed. Many thanks!

[zw963]

After hitting "+" from dired, I guess that as soon you enter "app" helm is completing to "apple" , right ?
So at this time (or before entering "app") hit C- now you can write "app" without helm completing to "apple".

This help me a lot, Thanks.

[cute-jumper]

@thierryvolpiatto I wonder whether it is worth making the regexp customizable? Currently it makes all commands starting with dired- behave the same. When using +, R, this is nice. But when using j, it's kind of annoying.

I ask this because this is kind of an "undocumented" feature. I'm surprised to see the helm-read-file-name behave differently when using dired commands. After some sort of efforts I finally figured out the dired- commands are explicitly excluded in helm-ff-move-to-first-real-candidate. If the feature can be controlled by the users, it would be nice.

[xuchunyang]

I pushed a fix for j. However, user still can't control it.

[thierryvolpiatto]

Junpeng Qiu <notifications@github.com> writes:

@thierryvolpiatto I wonder whether it is worth making the regexp customizable? Currently it makes all commands starting with dired- behave the same. When using +, R, this is nice. But when using j, it's kind of annoying.

You ask in the subject how to disable helm-completion for creating directories in Dired, then you ask for customizing the regexp preventing to go to first real candidate in dired saying that "+" (create directory) is nice, an then you say that it's annoying only with "j". So I guess what you really want is disabling helm for "j" only, right ?

I ask this because this is kind of an "undocumented" feature. I'm surprised to see the helm-read-file-name behave differently when using dired commands. After some sort of efforts I finally figured out the dired- commands are explicitly excluded in helm-ff-move-to-first-real-candidate. If the feature can be controlled by the users, it would be nice.

If the above is true, modifying the regexp which prevent dired commands from moving to first real candidate would disable the feature for ALL dired commands, which is not what you want apparently. So I suggest you disable helm completion for "j" only or you use instead `helm-find-files`. I personally don't use anymore dired, only `helm-find-files` which DTRT for all and in addition doesn't leave you with tons of dired buffers around. The feature of preventing in the dired buffers from moving to first real line was asked by dired users who think it's better like this, I have personally no opinion on this as I don't use dired. So if you want to disable only "j" you can use `helm-completing-read-handlers-alist`. `(add-to-list 'helm-completing-read-handlers-alist '(dired-goto-file . nil))`

…

-- Thierry

[thierryvolpiatto]

Chunyang Xu <notifications@github.com> writes:

I pushed a fix for j.

Thanks.

However, user still can't control it.

Perhaps a var containing a list of fns ? `(memq (intern-soft name) var)`

…

-- Thierry

[cute-jumper]

You ask in the subject how to disable helm-completion for creating directories in Dired, then you ask for customizing the regexp preventing to go to first real candidate in dired saying that "+" (create directory) is nice, an then you say that it's annoying only with "j". So I guess what you really want is disabling helm for "j" only, right ?

I forgot to mention the context. In fact, I'm trying to discuss about this line from helm-ff-move-to-first-real-candidate:

(not (string-match "\\`[Dd]ired-" (assoc-default 'name (helm-get-current-source))))

Two commits, 01205d2 and 0278d3c, are related to this issue so I guess it would be nice to continue here. And yes, I would like to make j behave differently from +. (And thanks, @xuchunyang 's newest commit seems to fix this particular problem.)