From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: cl-defgeneric vs random funcall in project.el Date: Fri, 31 Jul 2015 03:37:58 +0300 Message-ID: <55BAC366.1010803@yandex.ru> References: <86oaiwa57v.fsf@stephe-leake.org> <55B79B3F.1060200@yandex.ru> <86wpxj93r2.fsf@stephe-leake.org> <55B82A0C.5040709@yandex.ru> <86fv4782k2.fsf@stephe-leake.org> <55B92F76.7060104@yandex.ru> <86380686sm.fsf@stephe-leake.org> <55BA0AC4.7060906@yandex.ru> <86mvyd7jf0.fsf@stephe-leake.org> <55BA5BDD.1080009@yandex.ru> <86k2thz0dw.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1438303107 8761 80.91.229.3 (31 Jul 2015 00:38:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Jul 2015 00:38:27 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 31 02:38:22 2015 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 1ZKyL5-0007T7-Ll for ged-emacs-devel@m.gmane.org; Fri, 31 Jul 2015 02:38:19 +0200 Original-Received: from localhost ([::1]:42653 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKyL4-0004Pg-Rk for ged-emacs-devel@m.gmane.org; Thu, 30 Jul 2015 20:38:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKyKs-0004P6-T4 for emacs-devel@gnu.org; Thu, 30 Jul 2015 20:38:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKyKn-0007Cm-Qv for emacs-devel@gnu.org; Thu, 30 Jul 2015 20:38:06 -0400 Original-Received: from mail-wi0-x232.google.com ([2a00:1450:400c:c05::232]:36643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKyKn-0007BY-IE for emacs-devel@gnu.org; Thu, 30 Jul 2015 20:38:01 -0400 Original-Received: by wicgb10 with SMTP id gb10so12437509wic.1 for ; Thu, 30 Jul 2015 17:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=OZhooaqhmZMkT34doWo66wNS8qZtn4DsxQHVlFYBmK0=; b=dNsRBxE5sWFKSClM8bflEGZzIvnAE8qBA8TdrWmuyvK6EXTuHnR9vjwWciB3hpJz+q xEOWvACv2TamY/2+BlLWVz7OaaJMXyXIXnMBx/bO22nR6jYr1avQlCSfnbBZ7vogKyDW npqQ8h8HqDYP/OMqSku0zDw3GexHNcpsMgTfHDwn+GY7jpeqyRazg5sZycghEE0MbkHd MA1EuJeue4SwIRUtv1Cy1kUusi2M/QKP8opTky1G444U+NmdsoKGfdryylvwWoIst60c qVsI4vDAX+uAmZASi4HsYtAsQlwdQ/iPu0qB5QUYEfeosJ3Ukjs2gNrJgVzBhEg0i+/8 ubrQ== X-Received: by 10.180.87.199 with SMTP id ba7mr793943wib.81.1438303080932; Thu, 30 Jul 2015 17:38:00 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id u7sm1731024wif.3.2015.07.30.17.37.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2015 17:37:59 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: <86k2thz0dw.fsf@stephe-leake.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::232 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:188217 Archived-At: On 07/31/2015 02:33 AM, Stephen Leake wrote: > If the elisp project backend just used load-path as project-search-path, > what desired functionality would you lose? xref-find-references won't search inside the current project root. That's about all project-search-path is currently used for, but hopefully other uses will crop up in the future. They would fail similarly. > You have talked about limiting xref-find-regexp to some subset of the > files that are visible thru load-path; can you give a concrete > use case for that? Maybe if we have project-find-regexp-in-roots, it will only search inside project-roots. And project-find-regexp will search inside roots + search-path. It's unrelated to the issue above. > Well, we obviously disagree; every project manager _I've_ worked with > already produces a flat list. I've addressed that in the other message, I think. > I don't understand why you are so dead set against supporting those > project managers. One might call "always recursing" the "modern" mindset. For instance, when calling Ag (a popular recent re-implementation of Grep), you have to make extra effort *not* to recurse. There no corresponding option, even. > As long as I have the ability to override sufficient project and xref > features so I can write backends for the project managers I use, I'm ok. > It would be nice if more of the utilities were able to handle flat > paths, but I can always re-implement them. I hope you'll consider whether recursing is too harmful, in each case. >> We won't be able to use rgrep on the resulting directories, > > You can use grep; what's wrong with that? Not "rgrep". Instead of calling find constructed command-line arguments once and collecting results, you'll have to call grep for each directory you're interested in. And instead of find+grep, one could use Ag. >> but we'd still have to handle ignored files. > > That's no harder with a flat path than with a recursive path. I'm sure it'll be more involved than the current implementation of xref--rgrep-command.