From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Leo Newsgroups: gmane.emacs.devel Subject: Re: PATCH: Fix IDO interaction with uniquify.el Date: Wed, 5 May 2010 18:56:21 +0100 Message-ID: References: <87k4vf1zdh.fsf@telefonica.net> <87d417h0z6.fsf@stupidchicken.com> <87tyujz57h.fsf@telefonica.net> <87ockrz4eu.fsf@telefonica.net> <87pr57uw25.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1273095859 30562 80.91.229.12 (5 May 2010 21:44:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 5 May 2010 21:44:19 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 05 23:44:17 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O9mO8-0001bL-Qq for ged-emacs-devel@m.gmane.org; Wed, 05 May 2010 23:44:17 +0200 Original-Received: from localhost ([127.0.0.1]:45522 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9mNB-00046M-Ot for ged-emacs-devel@m.gmane.org; Wed, 05 May 2010 17:43:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O9ivK-0004OA-00 for emacs-devel@gnu.org; Wed, 05 May 2010 14:02:18 -0400 Original-Received: from [140.186.70.92] (port=37609 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9iuf-0003XS-Iy for emacs-devel@gnu.org; Wed, 05 May 2010 14:02:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O9iqt-0005XL-F3 for emacs-devel@gnu.org; Wed, 05 May 2010 13:57:44 -0400 Original-Received: from mail-wy0-f169.google.com ([74.125.82.169]:48546) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O9iqt-0005X8-Af for emacs-devel@gnu.org; Wed, 05 May 2010 13:57:43 -0400 Original-Received: by wyb33 with SMTP id 33so1742638wyb.0 for ; Wed, 05 May 2010 10:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=B5aoetBHKdw8R1+X082GPKvrRhP7DY7A5WrpqhK2vfI=; b=CVn2sb380AfUMR7nzgd/HQ0QcvQ/+Gh8iA9XOUScRqINVEbqIzhl7HuH2my6Qlqgiw 9hnKsnpBwvLvr5hVxUhu9yy7NejoCrkZzvctcBU7MubdrVQb2oELx34Fdgya0d8FW+Ar 1Y37n9PrnB8a2c20RdCf2o7HrQxqzU4kz8ltY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XP59jwi5G09TRg+cWwOoyyEybsUf0/2M/mMsZcjAkrbY3/uujaAcGiq3YOEOu/IWM/ toj2UBkbf1RxN+jhwywghegq3gCByg8FGgbIJ/QY+1UQ5wQ+bt6F9PzNDvY3/goN63fu W1Y//yrOObB3a3GaujIkOWiiuF+Z89vAYaGIo= Original-Received: by 10.227.137.84 with SMTP id v20mr3101371wbt.74.1273082181169; Wed, 05 May 2010 10:56:21 -0700 (PDT) Original-Received: by 10.216.156.139 with HTTP; Wed, 5 May 2010 10:56:21 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:124551 Archived-At: > What does exactly mean "kill virtual buffers"? If you mean removing > them from the buffer list, are you going to maintain a separate list, > instead of regenerating it from recentf-list anew for each > ido-switch-buffer, or are you going to modify recentf-list? 'kill virtual buffers' means removing them from recentf-list i.e. they cease to be virtual buffers. So the latter. > As for the duplicate entries, have you implemented it without using > uniquify? That does not seem too hard, and it's definitely cleaner. John and I have discussed whether uniquify should be used. He wants the virtual buffer name to follow the same style as that from uniquify. But in order to use unquify, some changes need to be made since at the moment uniquify is buffer oriented and virtual buffers are not buffers. Secondly to uniquify completely, the full list of files with same base name must be known and this adds complexity. I locally have a patch that completely handles duplicate basenames (about 40 lines of elisp without using caching) without using uniquify so I have some idea about the complexity. In the end we decide temporarily just adding some number (customisable) of parent directory. In practice one level of parent directory already significantly removes the chance of a file in recentf-list being ignored. > =A0 =A0Juanma Leo