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: Tue, 7 May 2013 22:42:38 +0800 Message-ID: References: <87txmfyb9n.fsf@gmail.com> <87vc6vulvo.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1367937772 15143 80.91.229.3 (7 May 2013 14:42:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 May 2013 14:42:52 +0000 (UTC) Cc: Leo Liu , emacs-devel@gnu.org To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 07 16:42:52 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 1UZj6O-0005ly-Bb for ged-emacs-devel@m.gmane.org; Tue, 07 May 2013 16:42:48 +0200 Original-Received: from localhost ([::1]:39174 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZj6N-0002rf-RD for ged-emacs-devel@m.gmane.org; Tue, 07 May 2013 10:42:47 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZj6K-0002r4-Gy for emacs-devel@gnu.org; Tue, 07 May 2013 10:42:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZj6I-00078t-Tq for emacs-devel@gnu.org; Tue, 07 May 2013 10:42:44 -0400 Original-Received: from mail-we0-x234.google.com ([2a00:1450:400c:c03::234]:33569) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZj6I-00078c-LF for emacs-devel@gnu.org; Tue, 07 May 2013 10:42:42 -0400 Original-Received: by mail-we0-f180.google.com with SMTP id n5so576728wev.25 for ; Tue, 07 May 2013 07:42:41 -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=dJ5KBuq0tLJHkTL8hv4D/mO62vewWUi+Pq+WAaDrpjA=; b=T0teCYaXus911dfhk8L5mPxWCeu5XELYZw6JluESr6OeHTzw8K4NAhJEiVL8ymTpWq TwMp0P3DzcwzlTyRd+YbSlEm4KauAgl5E5yQ5GMOoss6IN5GtJ5Z42EgWM7esX27BTxH sOOW42BKr5xg3/6RtFrhvkU0f5sQiaQL20vF92SF3U3uve25aqoweja0dnDGcxjY9msg znlaI6fU7HtB5p3zsYFXOOyrMI83edMZArO+/dXOE7hP1y9pUsB7xxMghBAEBHSbmyWO 8pk9QkjYXhuuTuIzsX8e9YW92nrZ17FJGE6sWWYZpHqJ/e1zRs6V+kG41RK24VAul5Cm eiVQ== X-Received: by 10.194.93.68 with SMTP id cs4mr4045182wjb.17.1367937758219; Tue, 07 May 2013 07:42:38 -0700 (PDT) Original-Received: by 10.217.116.8 with HTTP; Tue, 7 May 2013 07:42:38 -0700 (PDT) In-Reply-To: <87vc6vulvo.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::234 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:159391 Archived-At: On Tue, May 7, 2013 at 6:26 PM, Vitalie Spinu wrote: > What are those packages? ido-hacks uses it: https://github.com/scottjad/ido-hacks/blob/master/ido-hacks.el My flx package uses it: https://github.com/lewang/flx/blob/master/flx-ido.el > Not the best UI, but definitely not horrible, users can distinguish 2-3 > strings on very rare occasions. It makes implementation much faster and > solves a lot of hustle for lazy programmers:) I find presenting the same string with different properties to be horrendous. Using your example, but with completing-read: (let ((t1 (propertize "aaa" 'aaa 12)) (t2 (propertize "aaa" 'aaa 11))) (completing-read "?: " (list t1 t2 "sfd"))) Pressing I don't see "aaa" twice. When I select "aaa", the properties are stripped. Surely you can agree that ido should not blaze its own trail just to enable lazy programmers? > Look at imenu-anywhere. It happens to have same imenu tag in different > files. The package never relied on text properties because IDO was > broken and it wasn't necessary. Now the issue is solved, and relying on > text properties is a one-line change to the package. It all depends on > whether your patch is accepted or not. This is a terrible idea if ido facilitated such laziness. > Instead of proposing patch to ido, can you propose a patch to the > "packages" that needlessly use text properties? Because that would be much harder. Your proposal that I should do a harder thing so horrible UI can be easily implemented is not acceptable to me. > > There was an ido interface for ETAG selection floating around which I > never used, but I doubt it was uniquifying strings by adding location. > > In both cases above, one would need a non trivial pre-processing step to > sort it out. Yes. One should spend time to implement such pre-processing to give the user a better UI. -- Le