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: Allow xref to use other than current major-mode Date: Tue, 25 Aug 2015 20:05:55 +0300 Message-ID: <55DCA073.8090308@yandex.ru> References: <86fv37it65.fsf@stephe-leake.org> <55DC5612.9050704@yandex.ru> <867fojidv4.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 1440522381 20487 80.91.229.3 (25 Aug 2015 17:06:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Aug 2015 17:06:21 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 25 19:06:16 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 1ZUHfs-0004HH-35 for ged-emacs-devel@m.gmane.org; Tue, 25 Aug 2015 19:06:16 +0200 Original-Received: from localhost ([::1]:33624 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUHfr-0004yR-KF for ged-emacs-devel@m.gmane.org; Tue, 25 Aug 2015 13:06:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUHfn-0004vR-1I for emacs-devel@gnu.org; Tue, 25 Aug 2015 13:06:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUHfk-000627-9s for emacs-devel@gnu.org; Tue, 25 Aug 2015 13:06:10 -0400 Original-Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:34951) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUHfk-00061X-39 for emacs-devel@gnu.org; Tue, 25 Aug 2015 13:06:08 -0400 Original-Received: by wicne3 with SMTP id ne3so21333773wic.0 for ; Tue, 25 Aug 2015 10:06:07 -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=hqcU3bcl0fObrsqaOzE8k/iW+ggWn9875pnnnAcU1+c=; b=uoof5anZlS8/JQ9OJ+4MDal0Ydt+AIoKSSr7T1v+acO79a95JguA0Yo5/9gX/ipFdd TTbgMnTGbakPMTtSL1bXCZaCTAHcSEZgG0YD2MAL+w2c3KdtaPzvGxba5XGoTxHRvev/ IV30a5ddxx/L8CfGWOGNZNhh7wNFC6OAep3KVDZOOeTmKOWVwiVbZCNFev+NPUPeC9j4 MaKBtqqyE8Io5C+9K2n6KxQwpu8XJ4+/IE7hGU+XC55pT3MhS10j/xKX2Yj9aLI72itR 9ACG6JnBzan5TKN5r/yPbd7+aPbbT/55Xig8ou6YqF2iEMRnW498LT/H8EiE8YLZovkb Dpwg== X-Received: by 10.194.62.211 with SMTP id a19mr50377957wjs.126.1440522367349; Tue, 25 Aug 2015 10:06:07 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id ny7sm3527294wic.11.2015.08.25.10.06.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Aug 2015 10:06:06 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: <867fojidv4.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::22b 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:189169 Archived-At: On 08/25/2015 06:31 PM, Stephen Leake wrote: > cl-generic.el is preloaded, so we could use a cl-defgeneric, and > dispatch on (mode (eql )). A given implementation is, of course, free to use cl-defgeneric and dispatch on whatever it wants, internally. > To make such a minor mode work, xref--read-identifier could be a > cl-defgeneric that dispatches on (project But if it also > dispatches on (mode (eql )), each backend would have to > define all combinations; that's a pain. If a backend needs to dispatch based on the current language, it will. It will do that inside the method implementations. But many backends will only need to deal with one language, a couple, or won't really need to check the language of the current buffer. > I've started writing such a thing, but it gets defeated by the fact that > xref--read-identifier uses the buffer-local value of > xref-identifier-completion-table-function, which is set by elisp-mode > (or c-mode, etc, or by default to etags). There's no way to change that. A backend is a combination of xref-find-function, xref-i-c-t-function and xref-i-a-p-function. If a minor mode changes the current backend, it would need to set all these variables (but see the planned change mentioned above). > We could require the user to manually enable an xref minor mode in each > buffer, but that's not friendly. We have "globalized" minor modes, to be used in similar situations. > I guess a global xref backend could somehow reset that variable, in all > elisp buffers? Maybe a function on elisp-mode-hook. A minor mode function is indeed normally added to xxx-mode-hook, whether it's by user's hand, or somehow automatically. > So a better approach would be to define a way to disable emacs-lisp-mode > (and all other major-modes) setting the xref buffer-local variables, so > that the user choice of xref backend is respected. That would be much > simpler than having to add a function to all the major mode hooks (most > of which are unknown at load time). You're speaking from the standpoint of wanting a single, global xref backend everywhere for the duration of the Emacs session. As previous discussions showed, that approach isn't natural for everyone. > We could define a new global variable xref-global-backend; if nil (the > default), We've discussed a very similar proposal, very recently. As long as a minor mode can take over major mode's setting anyway, there's no point in adding this kind of explicit override. > major modes can set xref vars; if non-nil, it indicates which > particular global backend is in use. It could be a function that returns > a boolean indicating whether the global backend wants to control xref in > the current buffer. So a semi-global backend could provide C and Ada > xref, but not elisp xref, for example. It could be a list of such > functions; only if all return nil should the major mode set the xref > vars. Sounds like an unnecessary complication.