From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Peter Milliken Newsgroups: gmane.emacs.bugs,gmane.emacs.pretest.bugs Subject: bug#3662: Possible problem with ido-completing-read Date: Thu, 25 Jun 2009 05:45:11 +1000 Message-ID: <791153ba0906241245i7df59c39u49d8f356a4c7325b@mail.gmail.com> References: <791153ba0906231437j7de0768ag1523ff93bfeabb12@mail.gmail.com> <874ou6xg5h.fsf@escher.local.home> Reply-To: Peter Milliken , 3662@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016e645fabc6504d1046d1d5877 X-Trace: ger.gmane.org 1245873465 20870 80.91.229.12 (24 Jun 2009 19:57:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Jun 2009 19:57:45 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, 3662@emacsbugs.donarmstrong.com To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 24 21:57:37 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MJYbA-0003Z4-4d for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Jun 2009 21:57:37 +0200 Original-Received: from localhost ([127.0.0.1]:59357 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJYb9-0006gM-J9 for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Jun 2009 15:57:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJYb5-0006eZ-8i for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2009 15:57:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJYb0-0006bq-Da for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2009 15:57:30 -0400 Original-Received: from [199.232.76.173] (port=48727 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJYb0-0006bj-94 for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2009 15:57:26 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:44442) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJYaz-00072K-LT for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2009 15:57:26 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5OJvMeW003608; Wed, 24 Jun 2009 12:57:23 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n5OJo6uV002107; Wed, 24 Jun 2009 12:50:06 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Peter Milliken Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 24 Jun 2009 19:50:06 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 3662 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 3662-submit@emacsbugs.donarmstrong.com id=B3662.12458727251507 (code B ref 3662); Wed, 24 Jun 2009 19:50:06 +0000 Original-Received: (at 3662) by emacsbugs.donarmstrong.com; 24 Jun 2009 19:45:25 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5OJjHOi001350 for <3662@emacsbugs.donarmstrong.com>; Wed, 24 Jun 2009 12:45:18 -0700 Original-Received: by qyk41 with SMTP id 41so681536qyk.19 for <3662@emacsbugs.donarmstrong.com>; Wed, 24 Jun 2009 12:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=U7c5rOKzYYWyywPRvqQql15YBvMAQLzZRGpOboT/RMk=; b=eL50/pp5cc9ulYU2IcOrhcvjEnSzFmiWfZdo1VREtM3FynlE4nfJot47epL6WlTJAq aKo0YSUjPFyUpqPZv3SGtZm+5AF5FVfnKNZ14GxBE5lOD2Q4mIcnioGEoQlP/8YZhTxk ff9HfXmIDX23f1a/XQlUgDYehmBBbW8I2El1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HES54SUoU5dxPGUqDvbV93SSU98u6X3KL6rhohgj0jtx/Pb+t2F2wY6RTJ8uIJXBek aRiTbW7Y3NSKdBMh9Yo/VIYJ1lrCujWIMt3ICTBLamMYd6l8KuspdiU6S8+nTqHG/2+m IgPY1CdRg7nk6hnaRbDOAtwZ7Y2pcblPDoiy4= Original-Received: by 10.220.97.212 with SMTP id m20mr1924155vcn.27.1245872711336; Wed, 24 Jun 2009 12:45:11 -0700 (PDT) In-Reply-To: <874ou6xg5h.fsf@escher.local.home> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Wed, 24 Jun 2009 15:57:30 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:28955 gmane.emacs.pretest.bugs:24691 Archived-At: --0016e645fabc6504d1046d1d5877 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Steve - that allows it to work. Although the description for 'ido-mode is "Toggle ido speed-ups on or off..." So maybe if I waited a year or two ("speed-ups" must be off by default) then I would have eventually received the correct prompt/behaviour? :-) Obviously invoking ido-mode has some undescribed side-effect that allows the completing-read to work. Hopefully somebody will either fix this problem or put in a description in ido-completing-read that you have to turn on speed-ups first! Thanks greatly - I can now get my original defun working! :-) Peter On Wed, Jun 24, 2009 at 5:08 PM, Stephen Berman wrote: > On Wed, 24 Jun 2009 07:37:42 +1000 Peter Milliken < > peter.milliken@gmail.com> wrote: > > > This bug is also present in Emacs 22.3. I am attempting to use > > ido-completing-read in a defun and the function "hangs" at the prompt > > i.e. it does no completion at all, it will not allow me to cancel the > > command, or accept a string typed in followed by RET. > > > > I have produced a small test function to attempt to minimise possible > > problems on my part: > > > > (defun test () > > (interactive) > > (let ((a)(d)) > > (setq d '("abc" "xyz" "abe" "def")) > > (setq a (ido-completing-read "prompt: " d)))) > > > > My *understanding* of reading the defun documentation is that I should > > be able to type "a" (at the prompt) and have a completion list of > > "abc" and "abe" offered. But this does not happen, all I get is "a > > TAB". If I hit C-g nothing happens, the prompt line remains at the > > command line. > > I get this behavior as well (with GNU Emacs 23.1.50.1 > (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2009-06-23 on escher). > However, if I add `(ido-mode 1)' before the first setq, then it works as > I assume it's supposed to: typing `M-x test' shows "prompt: {abc | xyz | > abe | def}" in the minibuffer, and then typing `a' (without subsequent > TAB) shows "prompt: a[b] {abc | abe}", and `C-g' quits the minibuffer. > > Steve Berman > --0016e645fabc6504d1046d1d5877 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Steve - that allows it to work.

Although the desc= ription for 'ido-mode is "Toggle ido speed-ups on or off..."<= /div>

So maybe if I waited a year or two ("speed-up= s" must be off by default) then I would have eventually received the c= orrect prompt/behaviour? :-)

Obviously invoking ido-mode has some undescribed side-e= ffect that allows the completing-read to =A0work. Hopefully somebody will e= ither fix this problem or put in a description in ido-completing-read that = you have to turn on speed-ups first!

Thanks greatly - I can now get my original defun workin= g! :-)

Peter

On = Wed, Jun 24, 2009 at 5:08 PM, Stephen Berman <stephen.berman@gmx.net> wr= ote:
On Wed, 24 Jun 2009 07:37:42 +1000 Peter Mi= lliken <peter.milliken@gmail= .com> wrote:

> This bug is also present in Emacs 22.3. I am attempting to use
> ido-completing-read in a defun and the function "hangs" at t= he prompt
> i.e. it does no completion at all, it will not allow me to cancel the<= br> > command, or accept a string typed in followed by RET.
>
> I have produced a small test function to attempt to minimise possible<= br> > problems on my part:
>
> (defun test ()
> =A0=A0(interactive)
> =A0=A0(let ((a)(d))=A0
> =A0=A0 =A0(setq d '("abc" "xyz" "abe"= ; "def"))
> =A0=A0 =A0(setq a (ido-completing-read "prompt: " d))))
>
> My *understanding* of reading the defun documentation is that I should=
> be able to type "a<TAB>" (at the prompt) and have a co= mpletion list of
> "abc" and "abe" offered. But this does not happen,= all I get is "a
> TAB". If I hit C-g nothing happens, the prompt line remains at th= e
> command line.

I get this behavior as well (with GNU Emacs 23.1.50.1
(i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2009-06-23 on escher).
However, if I add `(ido-mode 1)' before the first setq, then it works a= s
I assume it's supposed to: typing `M-x test' shows "prompt: {a= bc | xyz |
abe | def}" in the minibuffer, and then typing `a' (without subseq= uent
TAB) shows "prompt: a[b] {abc | abe}", and `C-g' quits the mi= nibuffer.

Steve Berman

--0016e645fabc6504d1046d1d5877--