From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Le Wang Newsgroups: gmane.emacs.devel Subject: Re: fix for bug 10994 breaks ido customizations in major way Date: Fri, 3 May 2013 20:49:20 +0800 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b5d8cffa44f6504dbcfc78f X-Trace: ger.gmane.org 1367585373 10630 80.91.229.3 (3 May 2013 12:49:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 May 2013 12:49:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Leo Liu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 03 14:49:34 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UYFQZ-0000WG-EK for ged-emacs-devel@m.gmane.org; Fri, 03 May 2013 14:49:31 +0200 Original-Received: from localhost ([::1]:39092 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYFQY-0002Gf-Ut for ged-emacs-devel@m.gmane.org; Fri, 03 May 2013 08:49:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYFQR-0002GQ-SH for emacs-devel@gnu.org; Fri, 03 May 2013 08:49:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UYFQQ-0003BT-AR for emacs-devel@gnu.org; Fri, 03 May 2013 08:49:23 -0400 Original-Received: from mail-wg0-x233.google.com ([2a00:1450:400c:c00::233]:40780) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYFQQ-0003BM-1H for emacs-devel@gnu.org; Fri, 03 May 2013 08:49:22 -0400 Original-Received: by mail-wg0-f51.google.com with SMTP id b13so1524686wgh.18 for ; Fri, 03 May 2013 05:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mrh84IW/SnhV78QLye6bM1XvmVkyUvt9FU6onVGzbcI=; b=MO32uBov1sVdlOX39TFdw7/SADcZ/Df+mPEJnhulHyb0/RL+RZ6SZWNfajb+7UcIQ7 IbaD2gttOQd5qrg074t85BfXM0CcsGiViE5wF6atyV50t/Zwq0FEKbi+SUp/Jb256q98 3I9ezrCMZV3ZCeD40bEpW4FOnH25qwfz9skbtVIL+9BZ3T4ZpIg7hvzRg0o7/hgsF7eg NBNhK6dMMSdoz9B5Szn+HM/qM9usw698WRpLXzpOZKRDb/wA4NJt61XP2lDuhTFHgG5H LiS/bDGM219lnfgBVN+5KLQK9zjf9CteOR4hj4Gfcro7Ag0ZQc+x7uqjExAIeWpoLl/9 KGnA== X-Received: by 10.194.93.68 with SMTP id cs4mr13741063wjb.17.1367585360988; Fri, 03 May 2013 05:49:20 -0700 (PDT) Original-Received: by 10.217.116.8 with HTTP; Fri, 3 May 2013 05:49:20 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159275 Archived-At: --047d7b5d8cffa44f6504dbcfc78f Content-Type: text/plain; charset=ISO-8859-1 I sent this off list by accident. On Fri, May 3, 2013 at 12:13 PM, Leo Liu wrote: > On 2013-05-03 01:57 +0800, Le Wang wrote: > > bug: > > > http://emacs.1067599.n5.nabble.com/bug-10994-23-3-ido-mode-ido-next-match-ido-prev-match-work-wrong-with-same-elements-td300.html > > > > The committed fix converts equal to eq, causing any plugin that > propertizes > > the completion list to hang Emacs. > > > > This bug is filed as: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14334 > > > > The original bug report is essentially this: > > > > (ido-completing-read "dat is whrong -> " '("2" "3" "3" "3" "4" "5")) > > > > What's the expected behaviour in this case? Shouldn't the duplicates > from > > the list just be removed? > > I put in the fix. It was based on how ido-matches are built from > ido-cur-list. So it fixes the bug. > > I am not sure what new things you are doing with ido you will have to > look into this yourself.. > There are a few ido customizations floating around that propertizes text. This will break all of them. I don't think this fix is acceptable. > Ideally ido should not modified the list fed to it. i.e. That's not happening. The list passed to ido is not modified. ido-set-matches-1 returns a newlist, (ido-completing-read "dat is whrong -> " '("2" "3" "3" "3" "4" "5")) > > should be able to rotate for- band backwards without removing the dups. > It would be odd-looking if a user supply one list and ido display > another. > I asked for a use-case of a completion list with duplicate strings. Do you have one? If I do a completing read outside of ido from "emacs -Q" duplicates are not shown. I tried (completing-read ": " '("a" "ab" "a")) when I press only two items are shown. -- Le --047d7b5d8cffa44f6504dbcfc78f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I sent this off list by accident.

On Fri, May 3, 2013 at 12:13 PM, Leo Liu=A0<sdl.web@gmail.com>=A0wrote:
On 2013-= 05-03 01:57 +0800, Le Wang wrote:
> bug:
>=A0http://emacs.1067599.n5.nabble.com/bug-10994-= 23-3-ido-mode-ido-next-match-ido-prev-match-work-wrong-with-same-elements-t= d300.html
>
> The committed fix converts equal to eq, causing any plugin tha= t propertizes
> the completion list to hang Emacs.
>
> Th= is bug is filed as:=A0http://debbugs.gnu.org/cgi/bugreport.cgi?bug= =3D14334
>
> The original bug report is essentially this:
>
> (= ido-completing-read "dat is whrong -> " '("2" &q= uot;3" "3" "3" "4" "5"))
>
> What's the expected behaviour in this case? =A0Shouldn'= ;t the duplicates from
> the list just be removed?

I put= in the fix. It was based on how ido-matches are built from
ido-cur-list= . So it fixes the bug.

I am not sure what new things you are doi= ng with ido you will have to
look into this yourself..

There a= re a few ido customizations floating around that propertizes text. =A0This = will break all of them. =A0I don't think this fix is acceptable.
<= div class=3D"im">
=A0
Ideally ido should not modified the list fed= to it. i.e.

=A0That's not happening. =A0The list passed t= o ido is not modified. =A0ido-set-matches-1 returns a newlist,

(ido-completing-read "dat is whrong -> " '("2&qu= ot; "3" "3" "3" "4" "5"))=

should be able to rotate for- band backwards without removing= the dups.
It would be odd-looking if a user supply one list and ido display
anothe= r.

I asked for a use-case of a co= mpletion list with duplicate strings. =A0 Do you have one? =A0
If I do a completing read outside of ido from "emacs -Q&quo= t; duplicates are not shown.

I tried
=A0 =A0 (completing-read ": " '("a" &qu= ot;ab" "a"))

when I press <tab> only two items = are shown.
=


--=A0
Le
--047d7b5d8cffa44f6504dbcfc78f--