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: Sat, 1 Aug 2015 01:52:46 +0300 Message-ID: <55BBFC3E.2010405@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> <55BAC366.1010803@yandex.ru> <86fv44z94l.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 1438383194 5736 80.91.229.3 (31 Jul 2015 22:53:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Jul 2015 22:53:14 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 01 00:53:08 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 1ZLJAq-0004Ey-7f for ged-emacs-devel@m.gmane.org; Sat, 01 Aug 2015 00:53:08 +0200 Original-Received: from localhost ([::1]:46263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLJAp-00031t-F7 for ged-emacs-devel@m.gmane.org; Fri, 31 Jul 2015 18:53:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLJAc-000314-Ef for emacs-devel@gnu.org; Fri, 31 Jul 2015 18:52:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZLJAY-0008Gm-9K for emacs-devel@gnu.org; Fri, 31 Jul 2015 18:52:54 -0400 Original-Received: from mail-wi0-x233.google.com ([2a00:1450:400c:c05::233]:36065) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLJAX-0008Fh-U2 for emacs-devel@gnu.org; Fri, 31 Jul 2015 18:52:50 -0400 Original-Received: by wicgj17 with SMTP id gj17so35628874wic.1 for ; Fri, 31 Jul 2015 15:52:49 -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=byW7XK5mqruyvw3wZPbenxI8GaZ6zxhBEdWphAIb+0Q=; b=GhACn58GhjdNAH/f0s9Qr8qQUJcSVTGYKaDcl2IZjlG3551FcpDU16YOgWzRSwUvW0 ykzalqx91R+MsW7FzCdLExt9HvOFvNpvi3qIWSuWF3Uz43PeGjMF/9xb/d9aLWC/rqeu vh4n4DwLsON/eZnXLjJIqyodIkZQSgwjIKElR7zs422dCpsD/KgZ/N0Xcp3aXUBTE/dn Zq7dqPf4nrP7eHzkxbe9vvU7ZE8vFSA8d6uNEymHNMoPWui6Tn2I49qDAV02CB5KH3Ow 5ekfRD2cbHVr9roVCt9qm2UJWAPs5b7bG5q/10SnASa5v3REviyi14ax2I2qwUvDl7dX nhQg== X-Received: by 10.194.86.161 with SMTP id q1mr11154483wjz.18.1438383169240; Fri, 31 Jul 2015 15:52:49 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id be9sm9356557wjb.26.2015.07.31.15.52.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 15:52:48 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: <86fv44z94l.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::233 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:188251 Archived-At: On 07/31/2015 05:36 PM, Stephen Leake wrote: > It would help to be more specific. Since we disagree, you can't assume > I'll guess what you have in mind; my first response was "so why would > you want to?". To be truly persuasive, you need to anticipate that > response, and address it before it happens. I'm sorry, I think I've addressed that question in one (or several) previous messages. I'm not a native speaker, and simply writing that the first time takes a sizable amount of effort. Repeating, and rephrasing, and reiterating, adds to that. Further, I wasn't sure which aspect of the question you wanted addressed: the question was "which functionality", not "why". The assumption was that you're already clear on the latter. To sum up: false negative results (not finding a valid occurrence of a given symbol) are much worse than false positives (finding a false occurrence of the given symbol, for instance, finding words in README when looking for a Java method). So it's better when our default behavior, with zero configuration performed by the user (maybe yet, or maybe they're not going to configure anything further at all), leans toward false positives rather than false negatives. For those reasons, I've left the current implementation of project-search-path largely intact in the recent commit. If the backend-specialized implementation has no extra information (the user hasn't performed any relevant configuration), then project-search-path includes entire project-roots. > A concrete example directory structure: > ... > The user has set load-path to (".../myproj/lisp" "~/.emacs.d/elpa/..." > ".../emacs-25.0/share/..." ...) Maybe they didn't, but even if they did... > One search the user might want to do: find the name of an elisp function > in a test driver script file, to see how it is tested, while > simultaneously finding all places that function is used in the *.el > files, to review the test cases to ensure they are sufficient. Indeed. It's a common operation. > 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. A fancy project backend could have those, though, and the user would be able to switch to their heart's content. We are not discussing a fancy project backend here, though. 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. > 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. The VC project backend is simple, and requires minimal intervention from the user. We could add some variables (to be set via .dir-locals.el), but I don't want to have to add anything to my init.el as soon as I start working on a new project. For one thing, my .emacs.d is published on GitHub, for all to see. What you've described here, could be a separate project backend. One you're welcome to write. > Then, in the same place they add myproj/lisp to load-path, the user > adds: Again, in all likelihood they don't do that anywhere. As a real example, I have a few small Elisp one-file packages, the Git checkouts of which are never in load-path. During the (infrequent) bouts of their development, I evaluate the whole buffer, write the changes, test them interactively, then commit and push. Then wait a while while MELPA builds the new version, and upgrade the installed one via M-x list-packages U RET.