bug#11715: 24.1; Error in post-command-hook: wrong-number-of-arguments - read-file-internal

bug#11715: 24.1; Error in post-command-hook: wrong-number-of-arguments - read-file-internal

[Drew Adams]

Not in emacs -Q, and I do not know how to reproduce it.
 
I get this sometimes:
 
Error in post-command-hook (#[nil \300\301!\207 [run-hooks
icomplete-post-command-hook] 2]): (wrong-number-of-arguments (lambda
nil (let ((minibuffer-completing-file-name t))
(completion-table-in-turn (quote completion--embedded-envvar-table)
(quote completion--file-name-table)))) 3)
 
That looks like someone (Icicles? Icomplete?) put this function on
post-command-hook:
 
(lambda () (let ((minibuffer-completing-file-name t))
(completion-table-in-turn (quote completion--embedded-envvar-table)
(quote completion--file-name-table))))
 
FWIW, I'm not aware of Icicles doing anything like that - I don't see
any code that is similar.  But I cannot say that it doesn't do something
that leads to that.
 
The `let' body in that sexp is just the definition of
`read-file-name-internal':
 
(defalias 'read-file-name-internal
  (completion-table-in-turn 'completion--embedded-envvar-table
                            'completion--file-name-table)
  "Internal subroutine for `read-file-name'.  Do not call this.")
 
This is that definition (symbol-function), un-byte-compiled:
 
(closure
 ((tables completion--embedded-envvar-table completion--file-name-table)
  t)
 (string pred action)
 (completion--some
  (lambda
    (table)
    (complete-with-action action table string pred))
  tables))
 
Hoping some of this info might ring a bell for Stefan.
It means little to me.
 
(I also do not recall whether this occurred in the release itself
or in a (post|parallel-to)-release development build.  If I had to
guess I'd say it occurs in both.)
 
In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600)
 of 2012-06-10 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

bug#11715: 24.1; Error in post-command-hook: wrong-number-of-arguments - read-file-internal

[Stefan Monnier]

> Error in post-command-hook (#[nil \300\301!\207 [run-hooks
> icomplete-post-command-hook] 2]): (wrong-number-of-arguments (lambda
> nil (let ((minibuffer-completing-file-name t))
> (completion-table-in-turn (quote completion--embedded-envvar-table)
> (quote completion--file-name-table)))) 3)

This says that while running icomplete's post-command-hook, someone
tried to call:

> (lambda () (let ((minibuffer-completing-file-name t))
> (completion-table-in-turn (quote completion--embedded-envvar-table)
> (quote completion--file-name-table))))

with 3 arguments.
Now, grepping for minibuffer-completing-file-name, I don't see anywhere
where we could build such a function.  Could it come from some unbundled
Elisp code (e.g. Icicles)?


        Stefan

bug#11715: 24.1; Error in post-command-hook: wrong-number-of-arguments - read-file-internal

[Drew Adams]

> > Error in post-command-hook (#[nil \300\301!\207 [run-hooks
> > icomplete-post-command-hook] 2]): (wrong-number-of-arguments (lambda
> > nil (let ((minibuffer-completing-file-name t))
> > (completion-table-in-turn (quote completion--embedded-envvar-table)
> > (quote completion--file-name-table)))) 3)
> 
> This says that while running icomplete's post-command-hook, someone
> tried to call:
> 
> > (lambda () (let ((minibuffer-completing-file-name t))
> > (completion-table-in-turn (quote completion--embedded-envvar-table)
> > (quote completion--file-name-table))))
> 
> with 3 arguments.
> Now, grepping for minibuffer-completing-file-name, I don't 
> see anywhere where we could build such a function.  Could it come from 
> some unbundled Elisp code (e.g. Icicles)?

Possibly, but I don't see how/where.

The code inside the `let' is the defalias of `read-file-name-internal'.  That
should be some hint to who constructs that function.

Grepping the Icicles (and other 3rd-party code I use) for
`minibuffer-completing-file-name', I do not see anywhere that such a function
(or even something similar) is built.

And grepping for `read-file-name-internal' finds nothing that seems related.

The only place Icicles binds `minibuffer-completing-file-name' to t is in
`icicle-read-file-name', which, after doing some unrelated stuff just binds
`read-file-name-function' to nil and calls `read-file-name' (thus using the
default behavior for `read-file-name').

Icomplete runs only `icomplete-exhibit' on `icomplete-post-command-hook' (hence
on `post-command-hook') AFAICT.

I checked all of this code before filing the bug report, and checked it again
just now.  Any idea?  What would construct a function of no args that is
essentially `read-file-name-internal' and put it on `post-command-hook' (and
apparently in or around icompletion, since I see the error only in that
context)?

bug#11715: 24.1; Error in post-command-hook: wrong-number-of-arguments - read-file-internal

[Stefan Monnier]

> I checked all of this code before filing the bug report, and checked it again
> just now.  Any idea?

No, I don't see it.

> What would construct a function of no args that is essentially
> `read-file-name-internal' and put it on `post-command-hook'

As I said, it is *not* put on post-command-hook: it is run by
Icomplete's post-command-hook, so the error could be because that
function was put in minibuffer-completion-table or
minibuffer-completion-predicate (and hence called by
icomplete-completions), or even on icomplete-post-command-hook.
Can you check some of those variables?
If you can find a way to trigger the problem with
M-: (run-hooks 'icomplete-post-command-hook) RET then we could debug it
a bit more easily (e.g. get a backtrace, use edebug, ...).


        Stefan

bug#11715: 24.1; Error in post-command-hook: wrong-number-of-arguments - read-file-internal

[Drew Adams]

> > What would construct a function of no args that is essentially
> > `read-file-name-internal' and put it on `post-command-hook'
> 
> As I said, it is *not* put on post-command-hook:
> it is run by Icomplete's post-command-hook

Don't know what you're insisting about.  I was clear about that:

   Icomplete runs only `icomplete-exhibit' on
   `icomplete-post-command-hook' (hence on `post-command-hook')".
   Icomplete runs its hook on `post-command-hook'...

(add-hook 'post-command-hook
	     (lambda () (run-hooks 'icomplete-post-command-hook))
	     nil t)

> so the error could be because that
> function was put in minibuffer-completion-table or
> minibuffer-completion-predicate (and hence called by
> icomplete-completions), or even on icomplete-post-command-hook.
> Can you check some of those variables?

I have checked them and did not find anything.  But the problem does not occur
all the time.  And, IIRC, it seems to occur once and then go away.  (I'm not
certain of that.)

And as you know it is difficult (~impossible) to use the debugger with the
Icomplete code.

FWIW, I'm guessing also that if that function were somehow put into
`minibuffer-completion-*' then I would see an error message sooner and in other
places.

> If you can find a way to trigger the problem with
> M-: (run-hooks 'icomplete-post-command-hook) RET then we 
> could debug it a bit more easily (e.g. get a backtrace, use edebug, ...).

Agreed.  If I could.  So far, I don't know how to repro the problem.

FWIW, I don't see the error right now.  I try `M-x forw' (to get Icomplete to
kick in), and then I try `M-: (run-hooks 'icomplete-post-command-hook)'.  It
does not appear to do anything (besides show the completions), and it returns
nil.  And if I instead do `M-: icomplete-post-command-hook' it says only
`(icomplete-exhibit)', as expected.

I will try to keep my eyes open and see if I can find out anything more the next
time I see the error.  Dunno what else to look at.  I realize that you cannot do
more at this point either.

bug#11715: 24.1; Error in post-command-hook: wrong-number-of-arguments -read-file-internal

[Drew Adams]

I found the problem - in my version of `icomplete-completions' (in
`icomplete+.el').  Thanks for your help.

FYI -

I make these changes to the vanilla version of `icomplete-completions':

1. Prepend the total number of candidates.
2. Sort candidates alphabetically, put them in a different face,
   and separate them more (2 spaces instead of ",").
3. Highlight the key-binding text.  Truncate it if too long.
4. Append the number of remaining cycle candidates (for Icicles).

The problem was that when I updated the Emacs 23 code to fit the vanilla Emacs
24 changes I understood things only partially.

In particular:

I do not use `completion-all-sorted-completions', since I need the number of
COMPS and I do not need the sort order that `c-a-s-c' provides.  So I do not use
LAST or BASE-SIZE.

Where I went wrong was replacing this code:

(if (and base-size (> base-size 0))
    (completion-try-completion name candidates predicate (length name) md)
  ;; If the COMPS are 0-based, the result should be the same with COMPS.
  (completion-try-completion name comps nil (length name) md)))

Since I do not use BASE-SIZE I tried using just the second `if' clause, without
really understanding things.  That was the mistake, as I'm sure you can tell.

It worked OK when the arg CANDIDATES was an alist, but not when it was a
function.

I changed the code to just (try-completion name candidates predicate), and it
seems to work well now.

There is unfortunately no description of any of the arguments in the doc string.
Apparently CANDIDATES corresponds to the COLLECTION arg of `completing-read' (is
that correct in all respects?).  If so, you might consider renaming it
COLLECTION.

And you might consider documenting the args.  Perhaps something like this:

NAME is the name to complete.
COLLECTION is the collection of candidates to match.  See
`completing-read' for its possible values.
PREDICATE filters matches: they succeed only if it returns non-nil.
REQUIRE-MATCH non-nil means the input must match a candidate.

(Maybe REQUIRE-MATCH corresponds to REQUIRE-MATCH in `completing-read', but
that's not clear to me.)

The possibility of arg CANDIDATES being a function is not new in Emacs 24, but
in Emacs 23 the Icomplete code was different and I did not run into such an
error.

(BTW, AFAICT there is nothing in the Emacs 23 NEWS about Icomplete supporting
file-name completion.)

Anyway, thanks for your help.  I will close this bug.