From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vitalie Spinu Newsgroups: gmane.emacs.devel Subject: Re: fix for bug 10994 breaks ido customizations in major way Date: Tue, 07 May 2013 12:26:03 +0200 Organization: EUR Message-ID: <87vc6vulvo.fsf@gmail.com> References: <87txmfyb9n.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1367922377 2853 80.91.229.3 (7 May 2013 10:26:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 May 2013 10:26:17 +0000 (UTC) Cc: Leo Liu , emacs-devel@gnu.org To: Le Wang Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 07 12:26:15 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 1UZf67-0001ql-Kp for ged-emacs-devel@m.gmane.org; Tue, 07 May 2013 12:26:15 +0200 Original-Received: from localhost ([::1]:58964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZf67-0005cW-8e for ged-emacs-devel@m.gmane.org; Tue, 07 May 2013 06:26:15 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41719) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZf60-0005aQ-Ob for emacs-devel@gnu.org; Tue, 07 May 2013 06:26:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZf5y-0008KU-0z for emacs-devel@gnu.org; Tue, 07 May 2013 06:26:08 -0400 Original-Received: from mail-wg0-x236.google.com ([2a00:1450:400c:c00::236]:61488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZf5x-0008KP-Qg for emacs-devel@gnu.org; Tue, 07 May 2013 06:26:05 -0400 Original-Received: by mail-wg0-f54.google.com with SMTP id x12so405221wgg.33 for ; Tue, 07 May 2013 03:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:organization:references:date :in-reply-to:message-id:user-agent:mime-version:content-type; bh=6JGQGVzhJ7iQ8PmzZQIHCxajXve8HoXHoS02RdrlR28=; b=0qjnETwYg9/Rqes8KmA6j7mTXOMz/0api/zfCSiXIBCl+HDz3WnypL28vGOVe1refe Nkn+CblH3LzZl0R8dxwnByMGsipzSs9xD1L1cauTvudVNm5vHA7qsHyW+uEuLSxZiCOE xfZ343TIdAFzu9EGiDOvNbQnDxmSDAqT3Y4BjuJMjVDkDcKaQ5JoSVwtfojVC3jbUKbi vO9HA8MvORXClKnauxk7xFxESDxS4A5LtLRg3lx7YCp5ZboHzqJBhF8y/SALQPvDEkFi /s8h/Hm2COZCz5HHJVLrtPFvPnNzVD7oiMDoXFmE9DjgSTRAbEo92Qje7ScSUAQ94IfK ixeQ== X-Received: by 10.194.176.164 with SMTP id cj4mr2163071wjc.58.1367922365092; Tue, 07 May 2013 03:26:05 -0700 (PDT) Original-Received: from localhost (dhcp-077-249-018-128.chello.nl. [77.249.18.128]) by mx.google.com with ESMTPSA id er17sm1988107wic.0.2013.05.07.03.26.03 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 03:26:04 -0700 (PDT) In-Reply-To: (Le Wang's message of "Tue, 7 May 2013 17:35:23 +0800") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::236 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:159388 Archived-At: >> Le Wang >> on Tue, 7 May 2013 17:35:23 +0800 wrote: >> There are plenty of applications that might need same strings but with >> different meaning. > No there aren't. Because this was completely broken in 24.3.1 until > the fix was checked in for 10994. Yes, I was bearing the behavior before, as everyone else did, because it wasn't happening too often. >> For example ido for tag or imenu navigation, there >> might be several locations where a symbol is used/defined. > This is a good reason for including a line#, class, etc. Why only > text-properties? Because it does require quite a fair amount of prepossessing and also post-processing. I think users are quite fine to see 2-3 strings and they understand, depending on the context, what repeated string signify. > Your examples are contrived and not in the wild at all. I say again, > only HEAD has the ability to handle repeated runs of strings. > BUT the cost of adding this functionality is breaking packages that > add text properties ... Packages that actually __exist__. What are those packages? They can remove text properties, or even not collect them in the first place, that is definitely easier than adding line-nums/files to repetitive strings. >> Currently >> >> (let ((t1 (propertize "aaa" 'aaa 12)) >> (t2 (propertize "aaa" 'aaa 11))) >> (ido-completing-read "?: " (list t1 t2 "sfd"))) >> >> works as expected. And the above patch breaks that. > That would be a horrible UI. Luckily AFAICT, it hasn't happened. 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:) > That's why I say there is no actual valid use-case for repeating the > same string in completions. 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. Instead of proposing patch to ido, can you propose a patch to the "packages" that needlessly use text properties? 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. Vitalie