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: Wed, 29 Jul 2015 04:19:08 +0300 Message-ID: <55B82A0C.5040709@yandex.ru> References: <86oaiwa57v.fsf@stephe-leake.org> <55B79B3F.1060200@yandex.ru> <86wpxj93r2.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 1438132775 29555 80.91.229.3 (29 Jul 2015 01:19:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Jul 2015 01:19:35 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 29 03:19:29 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 1ZKG1o-0006PX-KW for ged-emacs-devel@m.gmane.org; Wed, 29 Jul 2015 03:19:28 +0200 Original-Received: from localhost ([::1]:32974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKG1n-0007qZ-Eh for ged-emacs-devel@m.gmane.org; Tue, 28 Jul 2015 21:19:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKG1b-0007qR-Es for emacs-devel@gnu.org; Tue, 28 Jul 2015 21:19:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKG1Y-0007ue-9v for emacs-devel@gnu.org; Tue, 28 Jul 2015 21:19:15 -0400 Original-Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:36505) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKG1Y-0007uZ-1y for emacs-devel@gnu.org; Tue, 28 Jul 2015 21:19:12 -0400 Original-Received: by wicgb10 with SMTP id gb10so179077895wic.1 for ; Tue, 28 Jul 2015 18:19:11 -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=f+DpsgVrxJMx8RjEdbwJGVwYmgbQAwQYdwLcgZU5DCQ=; b=L8nbxsQLFW576Di04jMDyzQXbxIDzU0ibkAPRFoePrqWZfJEfwA1HXSNIt79G4ZUQJ 507HIFAOWaxq44he/ERMwSy9Nt+6SAprmuASseB8J9rF7J9umVPnQGj4Ze1iWlPNQPvl JEpPePjAQE0UCV3JzN3/hzNeO3zY9evT7iroQclb8fKDfLgu2ht7o7WtvTafuev+iG/q /6Wx2giwn3tsh2Ozx+pzRKq0/1RCXMCZFyQGWWc3aF9Drd9ZOit3rMu6S4/NsHJu3lCA AgMwbvMkYSSZQa7YmTZvg9G34vJ3jNV0LYwOXOzMGFGpE/uw14xPAHdvZdNRvA313c4B ccFg== X-Received: by 10.194.123.4 with SMTP id lw4mr69362648wjb.94.1438132751360; Tue, 28 Jul 2015 18:19:11 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id gc4sm21596317wib.23.2015.07.28.18.19.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2015 18:19:10 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <86wpxj93r2.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::235 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:188151 Archived-At: On 07/29/2015 04:00 AM, Stephen Leake wrote: > Why would it use 'cl-call-next-method'? That would call the > default method, which is wrong; that's why we're overriding it. A project-specific implementation could call cl-call-next-method, to find out what the major mode thinks the search-path should be. > Nothing else in project.el currently suggests that > 'project-search-path-function' should be a list; the default method for > project-search-path doesn't treat it as a list. What is the use case > for this? I remember seeing something in the email chain; did that get > captured somewhere? The value is not a list. It's a function, which could take different values in different modes. If a project implementation is concerned with different languages, it could obtain the value of this variable corresponding to all major modes (using temporary buffers, for instance; or the author could just hardcode the list), then call those functions, and append them together. >> However, now that we've reached the consensus that project-search-path >> doesn't need to include the directories inside the current project, > > I never agreed to that. In fact, I thought the only thing we _did_ agree > on was that project-search-path included the main project. Sigh. Seriously? Here's a quote from one of your messages: """ So some specific change proposals: - Rename 'project-directories' to 'project-root-directories' or 'project-roots'. The current project root should always be first in the list. - 'project-search-path' should not include 'project-root-directories'. """