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: force initialization of a datatype? Date: Sat, 07 Nov 2015 12:30:13 -0600 Message-ID: <86ziypvf0q.fsf@stephe-leake.org> References: <86lhadybig.fsf@stephe-leake.org> <563A59BD.6010909@yandex.ru> <86ziyrwdce.fsf@stephe-leake.org> <563C9A02.2030601@yandex.ru> <86egg2waph.fsf@stephe-leake.org> <563E2676.1020109@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1446921054 22655 80.91.229.3 (7 Nov 2015 18:30:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Nov 2015 18:30:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 07 19:30:41 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 1Zv8G7-00062k-7g for ged-emacs-devel@m.gmane.org; Sat, 07 Nov 2015 19:30:39 +0100 Original-Received: from localhost ([::1]:44896 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv8G6-0008J8-8D for ged-emacs-devel@m.gmane.org; Sat, 07 Nov 2015 13:30:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50377) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv8Fy-0008In-Cc for emacs-devel@gnu.org; Sat, 07 Nov 2015 13:30:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zv8Fv-0004Op-6T for emacs-devel@gnu.org; Sat, 07 Nov 2015 13:30:30 -0500 Original-Received: from gproxy7-pub.mail.unifiedlayer.com ([70.40.196.235]:54035) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Zv8Fu-0004Ob-Vw for emacs-devel@gnu.org; Sat, 07 Nov 2015 13:30:27 -0500 Original-Received: (qmail 20552 invoked by uid 0); 7 Nov 2015 18:30:22 -0000 Original-Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 7 Nov 2015 18:30:22 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw4 with id eiWJ1r0072UdiVW01iWMmb; Sat, 07 Nov 2015 11:30:22 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa 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=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=qtqOOiqGOCEA:10 a=vaJtXVxTAAAA:8 a=vtNpzSFaBQYHqRazTQkA:9 Original-Received: from [76.218.37.33] (port=53399 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1Zv8Fl-0001qU-Qr; Sat, 07 Nov 2015 11:30:17 -0700 In-Reply-To: <563E2676.1020109@yandex.ru> (Dmitry Gutov's message of "Sat, 7 Nov 2015 18:27:34 +0200") 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: 70.40.196.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:193555 Archived-At: Dmitry Gutov writes: > On 11/07/2015 09:05 AM, Stephen Leake wrote: > >> I don't follow. >> >> `elisp-xref-find-def-functions' is a hook that is called from >> `elisp--xref-find-definitions'; why should it be in find-func? > > It would have a different name, of course, and maybe used indirectly > through calling some of the find-func functions. But like you > mentioned, we already have find-function-regexp-alist. > >> The only file that currently puts a function on that hook is >> cedet/mode-local.el; it adds similar functionality to >> `help-fns-describe-function-functions' and `find-function-regexp-alist'. > > Why can't we reuse the contents of those variables? `help-fns-describe-function-functions' is intended to be called from 'describe-function'; it puts the results in a buffer. `elisp-xref-find-def-functions' puts the results in a list of xrefs. So the code is different. `find-function-regexp-alist' is used by `find-function-search-for-symbol', which in turn is used by `xref-location-marker ((l xref-elisp-location))'. So we are reusing that variable. > I think the meat of the code that knows how to find Elisp entities > should be in one place. The code that _finds_ elisp entities is `find-function-search-for-symbol'; that is shared. The rest of the code is for display. There may be some minor refactoring opportunities, but the main differences between `help-fns-describe-function-functions' and `elisp-xref-find-def-functions' is that one outputs to a buffer, and the other to a list of xrefs. >> That code has a FIXME about moving it to >> `elisp-xref-find-def-functions'; there is already code in cl-generic >> that puts similar functionality on >> `help-fns-describe-function-functions' and `find-function-regexp-alist'. > > What if some new third-party facility adds a relevant element to > elisp-xref-find-def-funtcions, but not find-function-regexp-alist? Or > vice versa? Not all entries on `elisp-xref-find-def-functions' have a corresponding entry in `find-function-regexp-alist'; they are not equivalent. I think you meant `elisp-xref-find-def-functions' vs `help-fns-describe-function-functions'; whatever xref can display, describe-function should display, and vice versa. A difference between the list of things xref can display and those that describe-function can display is a bug (that includes more than just those two lists). There were a lot of such bugs when xref was introduced. I've fixed some of them with `elisp-xref-find-def-functions', others with other code in elisp--xref-find-definitions. There are still a few remaining; see the FIXMEs in elisp-mode.el. You seem to be suggesting that there should be a way to write one function for both lists; that's certainly not possible. We might be able to switch to a dispatching "display-function", with one backend for help buffers and one for xrefs. But that does not change the essential point that different code needs to be written for both. -- -- Stephe