From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: find-file-project Date: Wed, 20 Jan 2016 15:09:34 -0800 (PST) Message-ID: <3d71b360-d640-4e85-b735-82999d3cf5d4@default> References: <86pp1j4ejm.fsf@stephe-leake.org> <55F899EA.7050700@yandex.ru> <86lhc73wog.fsf@stephe-leake.org> <55F8F2FA.6060902@yandex.ru> <867fnq1oe9.fsf@stephe-leake.org> <55F9A13A.3070101@yandex.ru> <55FB01BD.1070909@yandex.ru> <568C6DE5.8040201@yandex.ru> <568F1327.30905@yandex.ru> <569DD470.2060603@yandex.ru> <569ED9F6.3050003@yandex.ru> <569EE733.6090406@yandex.ru> <569FAA57.5000302@yandex.ru> <56A00663.7050705@yandex.ru> <6028e88e-e79d-4e85-b759-0f5c75902da0@default> <56A0099A.5070305@yandex.ru> <1d448ddb-cb25-4c0a-80df-7321f83b13ad@default> <56A00F31.7050108@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1453331398 20299 80.91.229.3 (20 Jan 2016 23:09:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Jan 2016 23:09:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 21 00:09:45 2016 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 1aM1sn-0007iU-I9 for ged-emacs-devel@m.gmane.org; Thu, 21 Jan 2016 00:09:45 +0100 Original-Received: from localhost ([::1]:45418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aM1sm-00004w-Rq for ged-emacs-devel@m.gmane.org; Wed, 20 Jan 2016 18:09:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aM1sk-00004q-7s for emacs-devel@gnu.org; Wed, 20 Jan 2016 18:09:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aM1sh-0007Ig-1j for emacs-devel@gnu.org; Wed, 20 Jan 2016 18:09:42 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:17889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aM1sg-0007Ic-Qv for emacs-devel@gnu.org; Wed, 20 Jan 2016 18:09:38 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0KN9Zkq001128 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 23:09:36 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u0KN9ZvN002011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 23:09:35 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u0KN9ZGE022510; Wed, 20 Jan 2016 23:09:35 GMT In-Reply-To: <56A00F31.7050108@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:198473 Archived-At: > > Why do you think you need to screw with this longstanding feature? > > Would it be that hard for you to update _your_ code - to fit Emacs? >=20 > Not possible. all-completions is, like you say, documented to behave in > a certain way. >=20 > We want to introduce completion tables that perform a more lax kind of > completion. It would make sense if all-completions didn't work on them. It doesn't bother me (a priori) if you add something, without breaking anything. Subtracting functionality is a different story. Including `all-completions', `minibuffer-completion-table', etc. I don't understand why you can't use lax completion in connection with the existing framework (including `all-completions', `minibuffer-completion-table', etc.). I (and others) have been doing that for years, including for many different kinds of lax completion. What is so special about what you think you need? You no doubt have your reasons for doing things your own way. Why not do that in your own library (compatible or incompatible)?