discrepancy between `helm-read-file-name-handler-1` with 8 arguments versus `helm--completing-read-default` with 10 arguments

[00krishna]

Expected behavior

I use helm with Spacemacs, but I think I found a helm issue. I also appreciate that the lead developer is just doing bug fixes now, so I don't necessarily expect a resolution to this issue. But I figured I would certainly document the problem in case anyone else has a similar issue.

When using dired mode in spacemacs 0.200.13.x on emacs 26.1 I have inconsistent
behavior with the Rename and Copy operations. I can mark a couple of files
and then click R for rename. The first time this will usually work and I get
the prompt for the directory in which to move the files. The second time I try
and do this, I get an error message

apply: Wrong number of arguments: (8 . 8), 10

There does not seem to be anything else wrong, but it makes dired unusable.

NOTE:
I did try running emacs -Q and then executing the same sequence of commands in the Reproduction section. With the vanilla config, the commands work just fine. So something in the Spacemacs config is causing this though it is not clear whether that is a conflict with an existing package or something else.

Actual behavior (from emacs-helm.sh if possible, see note at the bottom)

I just observe the error message apply: Wrong number of arguments: (8 . 8), 10.
The files are not renamed or moved.

Steps to reproduce (recipe)

• Start Emacs
• Open dired mode with SPC f j
• navigate to desired directory
• mark two files with clicking on m
• click R to do a rename for the first time, and move the files to a new directory
• mark two more files by clicking m
• click R to rename the files again, and experience the error.

Backtraces if any (M-x toggle-debug-on-error)

Debugger entered--Lisp error: (wrong-number-of-arguments (8 . 8) 10)
  helm-read-file-name-handler-1("Rename jarrett-iccv-09.pdf to: " read-file-name-internal file-exists-p nil "~/Downloads/" file-name-history nil nil "dired-do-rename" "*helm-mode-dired-do-rename*")
  apply(helm-read-file-name-handler-1 ("Rename jarrett-iccv-09.pdf to: " read-file-name-internal file-exists-p nil "~/Downloads/" file-name-history nil nil "dired-do-rename" "*helm-mode-dired-do-rename*"))
  helm--completing-read-default("Rename jarrett-iccv-09.pdf to: " read-file-name-internal file-exists-p nil "~/Downloads/" file-name-history nil nil)
  apply(helm--completing-read-default ("Rename jarrett-iccv-09.pdf to: " read-file-name-internal file-exists-p nil "~/Downloads/" file-name-history nil nil))
  #f(advice-wrapper :override completing-read-default helm--completing-read-default)("Rename jarrett-iccv-09.pdf to: " read-file-name-internal file-exists-p nil "~/Downloads/" file-name-history nil nil)
  completing-read("Rename jarrett-iccv-09.pdf to: " read-file-name-internal file-exists-p nil "~/Downloads/" file-name-history nil)
  read-file-name-default("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil nil nil nil)
  read-file-name("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil nil nil nil)
  ido-read-file-name("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil nil nil nil)
  apply(ido-read-file-name ("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil nil nil nil))
  #f(advice-wrapper :override #f(advice-wrapper :override read-file-name-default helm--generic-read-file-name) ido-read-file-name)("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil nil nil nil)
  read-file-name("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil)
  apply(read-file-name ("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil))
  dired-mark-pop-up(nil move ("jarrett-iccv-09.pdf") read-file-name "Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil)
  dired-mark-read-file-name("Rename %s to: " "/home/krishnab/Downloads/" move nil ("jarrett-iccv-09.pdf") nil)
  dired-do-create-files(move dired-rename-file "Move" nil t "Rename")
  dired-do-rename(nil)
  funcall-interactively(dired-do-rename nil)
  call-interactively(dired-do-rename nil nil)
  command-execute(dired-do-rename)

Describe versions of Helm, Emacs, operating system, etc.

Emacs 26.1, Spacemacs 0.200.13.x on Ubuntu Linux 16.04x64 LTS.

Are you using emacs-helm.sh to reproduce this bug (yes/no):

No. Note from the additional information below, we already traced the issue in helm. So did not
need to do additional analysis through emacs-helm.sh.

IMPORTANT NOTE

Helm provides a script named emacs-helm.sh which runs Helm in a neutral
environment: no other packages and only minimal settings.

When possible, use it to reproduce your Helm issue to ensure no other package is
interfering.

To run it, simply switch to the directory where Helm is installed and call ./emacs-helm.sh.
If necessary you can specify emacs executable path on command line with "-P" option.

Thanks.

[00krishna]

I worked with a saavy elisp person through StackExchange to do some root cause analysis. Here is an excerpt from the answer.

https://stackoverflow.com/questions/52052485/emacs-dired-error-when-renaming-file-apply-wrong-number-of-arguments/52067576#52067576

[EXCERPT]
At first glance, this looks to me like a bug in the current version of helm.

Installing helm from MELPA, I see that helm-read-file-name-handler-1 accepts 8 arguments:

(helm-read-file-name-handler-1 PROMPT DIR DEFAULT-FILENAME MUSTMATCH INITIAL PREDICATE NAME BUFFER)

While helm--completing-read-default is guaranteed to call it with 10, as per the stack trace.

helm--completing-read-default looks up dired-do-rename in helm-completing-read-handlers-alist and finds that it is mapped to helm-read-file-name-handler-1. It then recognises the handler as being name-spaced as a helm function and, on that basis, calls it with 2 additional helm-specific arguments.

By default, helm-completing-read-handlers-alist includes:

(dired-do-rename . helm-read-file-name-handler-1)
(dired-do-copy . helm-read-file-name-handler-1)
(dired-do-symlink . helm-read-file-name-handler-1)
(dired-do-relsymlink . helm-read-file-name-handler-1)
(dired-do-hardlink . helm-read-file-name-handler-1))

So this issue affects all of those dired commands.

You could presuambly work around this by removing all of those.

e.g. M-x customize-option RET helm-completing-read-handlers-alist

[00krishna]

I worked with a saavy elisp person through StackExchange to do some root cause analysis. Here is an excerpt from the answer.

https://stackoverflow.com/questions/52052485/emacs-dired-error-when-renaming-file-apply-wrong-number-of-arguments/52067576#52067576

[EXCERPT]
At first glance, this looks to me like a bug in the current version of helm.

Installing helm from MELPA, I see that helm-read-file-name-handler-1 accepts 8 arguments:

(helm-read-file-name-handler-1 PROMPT DIR DEFAULT-FILENAME MUSTMATCH INITIAL PREDICATE NAME BUFFER)

While helm--completing-read-default is guaranteed to call it with 10, as per the stack trace.

helm--completing-read-default looks up dired-do-rename in helm-completing-read-handlers-alist and finds that it is mapped to helm-read-file-name-handler-1. It then recognises the handler as being name-spaced as a helm function and, on that basis, calls it with 2 additional helm-specific arguments.

By default, helm-completing-read-handlers-alist includes:

(dired-do-rename . helm-read-file-name-handler-1)
(dired-do-copy . helm-read-file-name-handler-1)
(dired-do-symlink . helm-read-file-name-handler-1)
(dired-do-relsymlink . helm-read-file-name-handler-1)
(dired-do-hardlink . helm-read-file-name-handler-1))

So this issue affects all of those dired commands.

You could presuambly work around this by removing all of those.

e.g. M-x customize-option RET helm-completing-read-handlers-alist

[phil-s]

Noting also that a conflict between helm and ido was the trigger for this error.

Without ido being active, helm uses helm--generic-read-file-name when these dired commands are used (rather than helm--completing-read-default), and the former function is only adding the 2 extra helm-specific arguments to an initial set of 6 giving the correct total of 8, which is obviously how it's intended to work.

To reproduce the error you can use M-x ido-everywhere, after which any of those dired commands goes through the process seen in the quoted stack trace, resulting in ido triggering completing-read which causes helm--completing-read-default to run, and the latter is sending an unexpected larger set of arguments to the handler.

It seems like each handler registered in helm-completing-read-handlers-alist may only be valid when invoked by particular helm functions, yet is still capable of being selected by other incompatible helm functions.

[phil-s]

Noting also that a conflict between helm and ido was the trigger for this error.

Without ido being active, helm uses helm--generic-read-file-name when these dired commands are used (rather than helm--completing-read-default), and the former function is only adding the 2 extra helm-specific arguments to an initial set of 6 giving the correct total of 8, which is obviously how it's intended to work.

To reproduce the error you can use M-x ido-everywhere, after which any of those dired commands goes through the process seen in the quoted stack trace, resulting in ido triggering completing-read which causes helm--completing-read-default to run, and the latter is sending an unexpected larger set of arguments to the handler.

It seems like each handler registered in helm-completing-read-handlers-alist may only be valid when invoked by particular helm functions, yet is still capable of being selected by other incompatible helm functions.

[thierryvolpiatto]

phil-s <notifications@github.com> writes:

Noting also that a conflict between `helm` and `ido` was the trigger for this error. Without `ido` being active, helm uses `helm--generic-read-file-name` when these dired commands are used (rather than `helm--completing-read-default`), and the former function is only adding the 2 extra helm-specific arguments to an initial set of 6 giving the correct total of 8, which is obviously how it's intended to work. To reproduce the error you can use `M-x ido-everywhere`,

See https://github.com/emacs-helm/helm/wiki/FAQ#helm-mode-conflict-with-ido-everywhere See also bug #1441. This is a duplicate of bug #1527.

…

-- Thierry

[thierryvolpiatto]

phil-s <notifications@github.com> writes:

Noting also that a conflict between `helm` and `ido` was the trigger for this error. Without `ido` being active, helm uses `helm--generic-read-file-name` when these dired commands are used (rather than `helm--completing-read-default`), and the former function is only adding the 2 extra helm-specific arguments to an initial set of 6 giving the correct total of 8, which is obviously how it's intended to work. To reproduce the error you can use `M-x ido-everywhere`,

See https://github.com/emacs-helm/helm/wiki/FAQ#helm-mode-conflict-with-ido-everywhere See also bug #1441. This is a duplicate of bug #1527.

…

-- Thierry

[phil-s]

If a change was to be made (and I'm not expecting one), my first impression is that perhaps helm-completing-read-handlers-alist should be split into two or more lists, and each of the functions utilising it be modified to access the particular list which was compatible with itself.

e.g. helm--completing-read-default could only see and invoke handlers which were compatible with the way it calls handlers, and likewise for helm--generic-read-file-name and any others...

Does that sounds like a sane approach? I don't know much about helm, so I'm just speculating.

[phil-s]

If a change was to be made (and I'm not expecting one), my first impression is that perhaps helm-completing-read-handlers-alist should be split into two or more lists, and each of the functions utilising it be modified to access the particular list which was compatible with itself.

e.g. helm--completing-read-default could only see and invoke handlers which were compatible with the way it calls handlers, and likewise for helm--generic-read-file-name and any others...

Does that sounds like a sane approach? I don't know much about helm, so I'm just speculating.

[thierryvolpiatto]

No, there is no problems with helm-completing-read-handlers-alist as it is, the point is that if ido-everywhere is enabled completing-read will be used (which is wrong for filenames) and without ido, read-file-name will be used which is what Helm expect.
The irony is that it is ido which is calling helm because helm-mode is enabled.
So which one is to blame ido or helm?
So if you use ido-mode don't use helm-mode and if you use helm-mode don't use ido but helm give you the possibility to use ido where needed which is not provided by ido.

[thierryvolpiatto]

No, there is no problems with helm-completing-read-handlers-alist as it is, the point is that if ido-everywhere is enabled completing-read will be used (which is wrong for filenames) and without ido, read-file-name will be used which is what Helm expect.
The irony is that it is ido which is calling helm because helm-mode is enabled.
So which one is to blame ido or helm?
So if you use ido-mode don't use helm-mode and if you use helm-mode don't use ido but helm give you the possibility to use ido where needed which is not provided by ido.

[thierryvolpiatto]

Note also that by removing the dired commands from helm-completing-read-handlers-alist you will hit bug #1441.

So to summarize there is no bug if you don't use ido-everywhere and helm-mode at the same time,
the wrong number of arguments is that ido is calling a completing-read whereas the helm handler is a read-file-name handler, so there is nothing wrong with the number of arguments.

[thierryvolpiatto]

Note also that by removing the dired commands from helm-completing-read-handlers-alist you will hit bug #1441.

So to summarize there is no bug if you don't use ido-everywhere and helm-mode at the same time,
the wrong number of arguments is that ido is calling a completing-read whereas the helm handler is a read-file-name handler, so there is nothing wrong with the number of arguments.

[thierryvolpiatto]

Note that a simple assertion at beginning of generic helm functions would be enough:

(cl-assert (null ido-everywhere)
             nil "ido-everywhere is incompatible with helm, please disable it")

[thierryvolpiatto]

Note that a simple assertion at beginning of generic helm functions would be enough:

(cl-assert (null ido-everywhere)
             nil "ido-everywhere is incompatible with helm, please disable it")

[phil-s]

Thanks Thierry. I was just about to suggest something similar...

Despite the non-standard name, ido-everywhere turns out to be a global minor mode defined with the standard macro; so we can test the ido-everywhere variable, react in ido-everywhere-hook, and disable it by passing an argument (ido-everywhere -1). Between all that, helm probably has the tools to prevent this conflict from happening.

[phil-s]

Thanks Thierry. I was just about to suggest something similar...

Despite the non-standard name, ido-everywhere turns out to be a global minor mode defined with the standard macro; so we can test the ido-everywhere variable, react in ido-everywhere-hook, and disable it by passing an argument (ido-everywhere -1). Between all that, helm probably has the tools to prevent this conflict from happening.

[phil-s]

I wondered whether the name indicated that originally ido-everywhere wasn't a minor mode, and that does turn out to be the case; but the change was 9 years ago in commit e78e280d7dbcd7b77ccba1fd1f914a45430abe0a which was released in emacs-23.2, so I imagine helm could safely rely on that.

[phil-s]

I wondered whether the name indicated that originally ido-everywhere wasn't a minor mode, and that does turn out to be the case; but the change was 9 years ago in commit e78e280d7dbcd7b77ccba1fd1f914a45430abe0a which was released in emacs-23.2, so I imagine helm could safely rely on that.

[thierryvolpiatto]

phil-s <notifications@github.com> writes:

Thanks Thierry. I was just about to suggest something similar...

Thanks.

Despite the non-standard name, ido-everywhere turns out to be a global minor mode defined with the standard macro; so we can test the ido-everywhere variable, react in ido-everywhere-hook, and disable it by passing an argument (ido-everywhere -1). Between all that, helm probably has the tools to prevent this conflict from happening.

Of course we can disable ourselves ido-everywhere in each helm generic functions, but I think this doesn't help the user, I think returning a good old error saying there is a conflict is more educative. Also the offending call of completing-read is IIUC in ido-read-internal because when ido-everywhere is enabled it advices only read-file-name and read-buffer so the completing-read-function is still a helm function, so when helm is called here, there is already a conflict.

…

-- Thierry

[thierryvolpiatto]

phil-s <notifications@github.com> writes:

Thanks Thierry. I was just about to suggest something similar...

Thanks.

Despite the non-standard name, ido-everywhere turns out to be a global minor mode defined with the standard macro; so we can test the ido-everywhere variable, react in ido-everywhere-hook, and disable it by passing an argument (ido-everywhere -1). Between all that, helm probably has the tools to prevent this conflict from happening.

Of course we can disable ourselves ido-everywhere in each helm generic functions, but I think this doesn't help the user, I think returning a good old error saying there is a conflict is more educative. Also the offending call of completing-read is IIUC in ido-read-internal because when ido-everywhere is enabled it advices only read-file-name and read-buffer so the completing-read-function is still a helm function, so when helm is called here, there is already a conflict.

…

-- Thierry

[phil-s]

Helm itself is enabled or disabled by helm-mode, no? (Apologies if I've misunderstood -- I don't actually use Helm or Ido, so I'm making some assumptions, but IIRC when I played with Helm I invoked helm-mode to get started...)

My thinking was that enabling helm-mode could potentially:

• Disable ido-everywhere, if it was already enabled.
• Register an ido-everywhere-hook function which would disable ido-everywhere should anything attempt to enable it.

Or can "each helm generic function" be used even when helm-mode is disabled?

In any case, "returning a good old error saying there is a conflict" sounds entirely reasonable and, as you point out, is more informative, even if it's (initially) a bit more disruptive.

[phil-s]

Helm itself is enabled or disabled by helm-mode, no? (Apologies if I've misunderstood -- I don't actually use Helm or Ido, so I'm making some assumptions, but IIRC when I played with Helm I invoked helm-mode to get started...)

My thinking was that enabling helm-mode could potentially:

• Disable ido-everywhere, if it was already enabled.
• Register an ido-everywhere-hook function which would disable ido-everywhere should anything attempt to enable it.

Or can "each helm generic function" be used even when helm-mode is disabled?

In any case, "returning a good old error saying there is a conflict" sounds entirely reasonable and, as you point out, is more informative, even if it's (initially) a bit more disruptive.

[thierryvolpiatto]

phil-s <notifications@github.com> writes:

Helm itself is enabled or disabled by helm-mode, no?

Not necessarily, all the helm native functions like helm-find-files, helm-M-x etc... can be used without enabling helm-mode.

(Apologies if I've misunderstood -- I don't actually use Helm or Ido, so I'm making some assumptions, but IIRC when I played with Helm I invoked helm-mode to get started...) My thinking was that enabling helm-mode could potentially: * Disable ido-everywhere, if it was already enabled. * Register an ido-everywhere-hook function which would disable ido-everywhere should anything attempt to enable it.

Yes that would work, but then we will have users complaining they have enabled ido and it is not working because helm is disabling it, and we will have to reexplain that ido is incompatible with helm, this is also why I would prefer raising directly an error.

Or can "each helm generic function" be used even when helm-mode is disabled?

No, they are never called when helm-mode is disabled, the incompatibility between helm and ido is only when helm-mode is enabled (and ido-everywhere also of course), but one can use a helm command e.g. helm-find-files or helm-M-x with ido-everywhere enabled without any error.

In any case, "returning a good old error saying there is a conflict" sounds entirely reasonable and, as you point out, is more informative, even if it's a bit more disruptive.

Yes. Thanks to look into this.

…

-- Thierry

[thierryvolpiatto]

phil-s <notifications@github.com> writes:

Helm itself is enabled or disabled by helm-mode, no?

Not necessarily, all the helm native functions like helm-find-files, helm-M-x etc... can be used without enabling helm-mode.

(Apologies if I've misunderstood -- I don't actually use Helm or Ido, so I'm making some assumptions, but IIRC when I played with Helm I invoked helm-mode to get started...) My thinking was that enabling helm-mode could potentially: * Disable ido-everywhere, if it was already enabled. * Register an ido-everywhere-hook function which would disable ido-everywhere should anything attempt to enable it.

Yes that would work, but then we will have users complaining they have enabled ido and it is not working because helm is disabling it, and we will have to reexplain that ido is incompatible with helm, this is also why I would prefer raising directly an error.

Or can "each helm generic function" be used even when helm-mode is disabled?

No, they are never called when helm-mode is disabled, the incompatibility between helm and ido is only when helm-mode is enabled (and ido-everywhere also of course), but one can use a helm command e.g. helm-find-files or helm-M-x with ido-everywhere enabled without any error.

In any case, "returning a good old error saying there is a conflict" sounds entirely reasonable and, as you point out, is more informative, even if it's a bit more disruptive.

Yes. Thanks to look into this.

…

-- Thierry

[00krishna]

Okay, so basically I needed to add the instruction:

  '(ido-everywhere nil)

to the custom-set-variables section of my config. Now things seem to be working. That is what was confusing me, since I did not know where to set the change. Meaning that I originally set this change higher up in my config but somewhere along the way it was getting overwritten and re-enabled. So now I set it at the very bottom and it seems to be working.

[00krishna]

Okay, so basically I needed to add the instruction:

  '(ido-everywhere nil)

to the custom-set-variables section of my config. Now things seem to be working. That is what was confusing me, since I did not know where to set the change. Meaning that I originally set this change higher up in my config but somewhere along the way it was getting overwritten and re-enabled. So now I set it at the very bottom and it seems to be working.

[phil-s]

@00krishna, I suggest that you M-x rgrep your config for ido-everywhere and see if you can identify what's turning it on in the first place, and then you could just disable that code.

[phil-s]

@00krishna, I suggest that you M-x rgrep your config for ido-everywhere and see if you can identify what's turning it on in the first place, and then you could just disable that code.

[thierryvolpiatto]

@00krishna I suggest also you separate the custom settings in another file to keep your init file clean i.e. only the settings you add yourself manually, for this use:

(setq custom-file "~/.emacs.d/.emacs-custom.el")
(load custom-file)

@phil-s Helm have much better tools to search files and buffers than rgrep ;-)

[thierryvolpiatto]

@00krishna I suggest also you separate the custom settings in another file to keep your init file clean i.e. only the settings you add yourself manually, for this use:

(setq custom-file "~/.emacs.d/.emacs-custom.el")
(load custom-file)

@phil-s Helm have much better tools to search files and buffers than rgrep ;-)