use of minibuffer in interactive spec code

use of minibuffer in interactive spec code

[Drew Adams]

I don't know if this is a bug or a bug fix. I would like to get some info about
it, if possible, to understand better. The behavior in this respect is new in
Emacs 23.2. It changed apparently sometime after this build:

GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2009-01-15 on LENNART-69DE564

I have this command, which is bound to a key during minibuffer completion in a
couple of cases:

(defun foo (dir)
  (interactive
   (list (read-directory-name
          "Dir: " nil nil
          (and (member cd-path '(nil ("./")))
               (null (getenv "CDPATH"))))))
  (cd dir)
  (...))

The `...' part makes use of the current value of
`minibuffer-completion-predicate'. It expects the value that that variable had
before this command was entered.

It turns out that I now need to bind `minibuffer-completion-predicate' in the
interactive spec. Otherwise, it has the value that is used for
`read-directory-name', which is `file-directory-p'.

(defun foo (dir)
  (interactive
   (let ((minibuffer-completion-predicate ; PROTECT IT
          minibuffer-completion-predicate))
     (list (read-directory-name
            "Dir: " default-directory default-directory
            (and (member cd-path '(nil ("./")))
                 (null (getenv "CDPATH")))))))
  (cd dir)
  (...))

It took me a while to discover this.

There was no change in the definition of `read-directory-name' between the two
Emacs builds mentioned. There was apparently a change in how the `interactive'
code is treated.

Previously, any recursive minibuffer use in the `interactive' spec was
apparently walled off from the body of the command, in the sense that
`minibuffer-completion-predicate' was not changed by that recursive minibuffer
read. That is no longer the case.

Is the new behavior intended?  Was it changed to fix some bug, as an enhancement
somehow, or by mistake?  Thx.

RE: use of minibuffer in interactive spec code

[Drew Adams]

> The behavior in this respect is new in Emacs 23.2.
> It changed apparently sometime after this build:
> 
> GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
>  of 2009-01-15 on LENNART-69DE564

Sorry, I meant to say that it changed sometime after the last pretest:
GNU Emacs 23.0.96.1 (i386-mingw-nt5.1.2600)
 of 2009-07-09 on SOFT-MJASON

Re: use of minibuffer in interactive spec code

[Stefan Monnier]

> Is the new behavior intended?  Was it changed to fix some bug, as an
> enhancement somehow, or by mistake?  Thx.

Looks like a bug.  At least, I'm probably to blame and I can't think of
any reason why this would be done on purpose.


        Stefan

Re: use of minibuffer in interactive spec code

[Stefan Monnier]

> It turns out that I now need to bind `minibuffer-completion-predicate' in the
> interactive spec. Otherwise, it has the value that is used for
> `read-directory-name', which is `file-directory-p'.

I cannot reproduce this problem on the trunk.  Can you?
Maybe the problem is that I didn't do quite the same as you did.
I did:

  emacs -Q

  (defun sm-foo (dir)
    (interactive
     (list (read-directory-name
            "Dir: " nil nil
            (and (member cd-path '(nil ("./")))
                 (null (getenv "CDPATH"))))))
    (message "m-c-p=%s" minibuffer-completion-predicate))
  (define-key minibuffer-local-completion-map [?\C-s ?\C-m] 'sm-foo)
  (setq enable-recursive-minibuffers t)

  M-x C-s C-m RET

and I see that minibuffer-completion-predicate was properly reset to commandp.

Can you give another recipe, maybe?


        Stefan

RE: use of minibuffer in interactive spec code

[Drew Adams]

> > It turns out that I now need to bind 
> > `minibuffer-completion-predicate' in the
> > interactive spec. Otherwise, it has the value that is used for
> > `read-directory-name', which is `file-directory-p'.
> 
> I cannot reproduce this problem on the trunk.  Can you?

I don't have a trunk. ;-) The latest Windows binary I have is 23.2. If a more
recent binary becomes available I can check that. Or if there is a particular
source file or two that I can download and try (assuming I can get through to
the HTTP page), I can do that.

But as I said, the breakage occurred apparently between the last pretest and
23.2. Since the last pretest was not long before 23.2, and since you think you
were the one who might have broken this, perhaps you can look at changes you
made during that short period.

Re: use of minibuffer in interactive spec code

[Stefan Monnier]

> But as I said, the breakage occurred apparently between the last
> pretest and 23.2.

I'm confused.  Your message seemed to refer to a "last pretest" in
january 2009:

   I don't know if this is a bug or a bug fix. I would like to get some
   info about it, if possible, to understand better.  The behavior in
   this respect is new in Emacs 23.2.  It changed apparently sometime
   after this build:
   
   GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
    of 2009-01-15 on LENNART-69DE564
   
> Since the last pretest was not long before 23.2, and
> since you think you were the one who might have broken this, perhaps
> you can look at changes you made during that short period.

If it's really between the last pretest and 23.2, then I'm not so sure
I'd be to blame since I haven't made (m)any changes around that time.

Have you tried my recipe?  What does it return?


        Stefan

RE: use of minibuffer in interactive spec code

[Drew Adams]

> I'm confused. Your message seemed to refer to a "last pretest" in
> january 2009:

I sent a followup message a few minutes after that:

> Sorry, I meant to say that it changed sometime after the last pretest:
> GNU Emacs 23.0.96.1 (i386-mingw-nt5.1.2600)
> of 2009-07-09 on SOFT-MJASON

However, I realize now that that was not a pretest, let alone the last. I was
mistaking 23.0.96.1 for 23.1.96.1. Sorry for the confusion.

I found a later binary to test with, so I've narrowed it down a bit more than
that July 2009 build. The problem was actually introduced sometime between the
following build and the first pretest (23.1.91.1, 2010-01-02). So that gives
about a 4-month window. I don't have another binary between the two to test,
unfortunately.

GNU Emacs 23.1.50.1 (i386-mingw-nt5.1.2600)
 of 2009-09-11 on LENNART-69DE564

As to a recipe: I get the same result as you, for your recipe.

I see the problem with my own setup - I don't have a simple recipe from emacs
-Q. But changing to older Emacs builds (2009-07-09 or older) fixes the problem.

Trying to find out where the problem is manifested by my code would take a
while, I'm afraid. I will just bind the predicate to prevent the problem. If I
do get time later to investigate further, I'll let you know. Thx.

Re: use of minibuffer in interactive spec code

[Stefan Monnier]

> As to a recipe: I get the same result as you, for your recipe.
> I see the problem with my own setup - I don't have a simple recipe
> from emacs -Q.  But changing to older Emacs builds (2009-07-09 or
> older) fixes the problem.

If that depends on your own config, then the world of possibilities is
much too large to start investigating on my side.  I.e. either narrow it
down to a much smaller window (i.e. a couple changes), or trim your
config until you find a simple recipe.


        Stefan

Re: use of minibuffer in interactive spec code

[Sean Sieger]

    > I cannot reproduce this problem on the trunk.  Can you?

    I don't have a trunk. ;-) The latest Windows binary I have is
    23.2. If a more recent binary becomes available I can check that.

Is this a good reason for publishing Windows binaries at
ftp.gnu.org/gnu/emacs/windows? like a weekly build, with a name
`emacs-2010xxxx-bin-i386.zip'?  I'd be willing to do that.

Re: use of minibuffer in interactive spec code

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Wed, 19 May 2010 12:04:27 -0400
> 
>     > I cannot reproduce this problem on the trunk.  Can you?
> 
>     I don't have a trunk. ;-) The latest Windows binary I have is
>     23.2. If a more recent binary becomes available I can check that.
> 
> Is this a good reason for publishing Windows binaries at
> ftp.gnu.org/gnu/emacs/windows? like a weekly build, with a name
> `emacs-2010xxxx-bin-i386.zip'?  I'd be willing to do that.

If you do this, alpha.gnu.org would be a better place, as that's where
development snapshots and alpha-quality versions are usually put.

Thanks.

posting Windows binaries of latest trunk dev code [was: use of minibuffer in interactive spec code]

[Drew Adams]

>     I don't have a trunk. ;-) The latest Windows binary I have is
>     23.2. If a more recent binary becomes available I can check that.
> 
> Is this a good reason for publishing Windows binaries at
> ftp.gnu.org/gnu/emacs/windows? like a weekly build, with a name
> `emacs-2010xxxx-bin-i386.zip'?  I'd be willing to do that.

That would indeed be welcome, wherever it might be posted.
But for me, at least, I would need HTTP access.

Re: posting Windows binaries of latest trunk dev code [was: use of minibuffer in interactive spec code]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Wed, 19 May 2010 09:21:40 -0700
> Cc: 
> 
> That would indeed be welcome, wherever it might be posted.
> But for me, at least, I would need HTTP access.

   http://alpha.gnu.org/gnu/emacs/

RE: posting Windows binaries of latest trunk dev code [was: use of minibuffer in interactive spec code]

[Drew Adams]

> > That would indeed be welcome, wherever it might be posted.
> > But for me, at least, I would need HTTP access.
> 
>    http://alpha.gnu.org/gnu/emacs/

Yes, that's why I mentioned HTTP. Such a location would be fine.

Re: posting Windows binaries of latest trunk dev code

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    > From: "Drew Adams" <drew.adams@oracle.com>
    > Date: Wed, 19 May 2010 09:21:40 -0700
    > Cc: 
    > 
    > That would indeed be welcome, wherever it might be posted.
    > But for me, at least, I would need HTTP access.

       http://alpha.gnu.org/gnu/emacs/

That's where I'll publish it this weekend.