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: Sat, 01 Aug 2015 05:21:42 -0500 Message-ID: <86h9ojjoll.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> <86k2thz0dw.fsf@stephe-leake.org> <55BAC366.1010803@yandex.ru> <86fv44z94l.fsf@stephe-leake.org> <55BBFC3E.2010405@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438424530 12578 80.91.229.3 (1 Aug 2015 10:22:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Aug 2015 10:22:10 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 01 12:22:00 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 1ZLTvT-00030i-CQ for ged-emacs-devel@m.gmane.org; Sat, 01 Aug 2015 12:21:59 +0200 Original-Received: from localhost ([::1]:53216 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLTvS-0004qN-Kk for ged-emacs-devel@m.gmane.org; Sat, 01 Aug 2015 06:21:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLTvO-0004q6-Tj for emacs-devel@gnu.org; Sat, 01 Aug 2015 06:21:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZLTvL-00023F-O0 for emacs-devel@gnu.org; Sat, 01 Aug 2015 06:21:54 -0400 Original-Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]:58555) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZLTvL-00022l-GO for emacs-devel@gnu.org; Sat, 01 Aug 2015 06:21:51 -0400 Original-Received: (qmail 13893 invoked by uid 0); 1 Aug 2015 10:21:50 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy2.mail.unifiedlayer.com with SMTP; 1 Aug 2015 10:21:50 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id zUMk1q0062UdiVW01UMnNo; Sat, 01 Aug 2015 10:21:49 -0600 X-Authority-Analysis: v=2.1 cv=Qc314Krv 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=uRRa74qj2VoA:10 a=vaJtXVxTAAAA:8 a=i5ikjADEgfrstqo5csEA:9 Original-Received: from [76.218.37.33] (port=63726 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZLTvE-00034z-SF for emacs-devel@gnu.org; Sat, 01 Aug 2015 04:21:45 -0600 In-Reply-To: <55BBFC3E.2010405@yandex.ru> (Dmitry Gutov's message of "Sat, 1 Aug 2015 01:52:46 +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: 69.89.18.3 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:188262 Archived-At: Dmitry Gutov writes: > On 07/31/2015 05:36 PM, Stephen Leake wrote: > >> It would be wrong to add the entire directory tree that contains .git; >> the user is using emacs 25, so they don't want to see the emacs 24.3 >> files. Obviously, there is a separate case where they do want to see >> those files; that's a different project configuration. > > It's really impractical, IMO, to have different project configurations > for different use cases. Not for me. > A fancy project backend could have those, > though, and the user would be able to switch to their heart's content. Switching is just selecting a different project file. > We are not discussing a fancy project backend here, though. I am. I want to ensure the core project API does not prevent me from writing the backends I want. It must also provide sufficient reason for me to use it; the fewer features I need that it has, the less reason I have to use it. > To be clear, here are the two main "separate cases": navigating to all > definitions, and aliases for different Emacs versions; navigating to > all references to a given function, again, in code for different Emacs > versions (to be able to rename them, for instance). As a project > maintainer, I want all of those visible and on the tips of my fingers, > because I need to maintain all code. Not just the code currently > loaded in my Emacs. Yes, that is a valid use case. And if the default project behavior, without any user add-search-path or add-ignores, gives you that, that's fine. >> We could provide: >> >> (defun project-create (root) >> ... >> `project-root-alist' associates root directories with project objects; >> ... >> (defun project-add-search-path (project path) >> ... >> (defun project-add-search-ignore (project ignores) > > Sorry, this is too much a centralized, manual configuration for my > taste. Is it a problem if they are present for others to use? We are discussing a core Emacs feature that will be used by many people; it cannot cater to only your personal opinions. > What you've described here, could be a separate project backend. One > you're welcome to write. Any backend that supports project files will need functions like these; project files are precisely centralized manual configuration. So they belong in the root class. If I end up writing everything in the backend, there's no point in using the "unified project interface". > As a real > example, I have a few small Elisp one-file packages, the Git checkouts > of which are never in load-path. Ok, I agree it would be good if the default project implementation supports this case. -- -- Stephe