From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: cl-defgeneric vs random funcall in project.el Date: Thu, 30 Jul 2015 18:33:31 -0500 Message-ID: <86k2thz0dw.fsf@stephe-leake.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438299259 19516 80.91.229.3 (30 Jul 2015 23:34:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Jul 2015 23:34:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 31 01:34:04 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 1ZKxKt-0004S0-OL for ged-emacs-devel@m.gmane.org; Fri, 31 Jul 2015 01:34:04 +0200 Original-Received: from localhost ([::1]:42509 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKxKs-0005Gw-Rf for ged-emacs-devel@m.gmane.org; Thu, 30 Jul 2015 19:34:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKxKd-0005Cb-HA for emacs-devel@gnu.org; Thu, 30 Jul 2015 19:33:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKxKZ-0003mJ-HY for emacs-devel@gnu.org; Thu, 30 Jul 2015 19:33:47 -0400 Original-Received: from gproxy5-pub.mail.unifiedlayer.com ([67.222.38.55]:50756) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZKxKZ-0003j7-4j for emacs-devel@gnu.org; Thu, 30 Jul 2015 19:33:43 -0400 Original-Received: (qmail 3699 invoked by uid 0); 30 Jul 2015 23:33:39 -0000 Original-Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 30 Jul 2015 23:33:39 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by CMOut01 with id ynZa1q00B2UdiVW01nZdia; Thu, 30 Jul 2015 17:33:38 -0600 X-Authority-Analysis: v=2.1 cv=NJxGpSKg c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=y7kgw_RnJtkA:10 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=zOBTXjUuO1YA:10 a=vaJtXVxTAAAA:8 a=xkIxLhQgJUd5Sk3lo0sA:9 Original-Received: from [76.218.37.33] (port=50584 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZKxKQ-00035w-NV for emacs-devel@gnu.org; Thu, 30 Jul 2015 17:33:34 -0600 In-Reply-To: <55BA5BDD.1080009@yandex.ru> (Dmitry Gutov's message of "Thu, 30 Jul 2015 20:16:13 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 67.222.38.55 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:188214 Archived-At: Dmitry Gutov writes: > On 07/30/2015 06:29 PM, Stephen Leake wrote: > >> The point of a "project backend" is that it knows _everything_ about the >> project. No stray hooks for users to pervert things. > > The problem is I (and others) have a lot of Elisp projects which don't > adhere to some particular structure. No particular project files, > aside from a .git repo, and maybe Makefile, or maybe some other -file. > > It's not even easy to identify it: maybe there are some .el files in > the root directory, but they might all be in a subdirectory. > > I want to support this use case. Ok. What does "support" mean here? If the elisp project backend just used load-path as project-search-path, what desired functionality would you lose? 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? >> I would write the vc implementation of project-search-path to return a >> flat list of all the directories under the vc root. > > The flat list is really out of the question. It really goes against my > intuition and every project backend will have to implement the logic > of producing this flat list based on some roots and a list of ignores. Well, we obviously disagree; every project manager _I've_ worked with already produces a flat list. I don't understand why you are so dead set against supporting those project managers. 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. > We won't be able to use rgrep on the resulting directories, You can use grep; what's wrong with that? > but we'd still have to handle ignored files. That's no harder with a flat path than with a recursive path. -- -- Stephe