From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: xref-find-matches and stuff Date: Tue, 12 May 2015 05:36:06 +0300 Message-ID: <83r3qmldyh.fsf@gnu.org> References: <5546DD4A.2080709@yandex.ru> <87r3qvnld1.fsf@gmail.com> <5548E08A.4090305@yandex.ru> <87mw1jndul.fsf@gmail.com> <554964CE.3040809@yandex.ru> <87oalxn756.fsf@gmail.com> <554AAD41.6060506@yandex.ru> <87vbg4lgn6.fsf@gmail.com> <554CB069.8090002@yandex.ru> <87sib7j9yf.fsf@gmail.com> <554CE8B2.7080408@yandex.ru> <87fv76kj0s.fsf@gmail.com> <83fv76p6ts.fsf@gnu.org> <55500A03.2020000@yandex.ru> <83oalrmabo.fsf@gnu.org> <55510FEA.8060804@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1431398196 29191 80.91.229.3 (12 May 2015 02:36:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 May 2015 02:36:36 +0000 (UTC) Cc: spinuvit@gmail.com, eller.helmut@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 12 04:36:26 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 1Ys03V-0000sg-KD for ged-emacs-devel@m.gmane.org; Tue, 12 May 2015 04:36:25 +0200 Original-Received: from localhost ([::1]:40530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ys03U-0006r1-LA for ged-emacs-devel@m.gmane.org; Mon, 11 May 2015 22:36:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ys03Q-0006qu-Md for emacs-devel@gnu.org; Mon, 11 May 2015 22:36:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ys03N-0003Xn-HU for emacs-devel@gnu.org; Mon, 11 May 2015 22:36:20 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:58634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ys03N-0003Xh-9W for emacs-devel@gnu.org; Mon, 11 May 2015 22:36:17 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NO700B00TNCIM00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Tue, 12 May 2015 05:36:15 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NO700BXITWFGC30@a-mtaout21.012.net.il>; Tue, 12 May 2015 05:36:15 +0300 (IDT) In-reply-to: <55510FEA.8060804@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:186445 Archived-At: > Cc: monnier@iro.umontreal.ca, spinuvit@gmail.com, emacs-devel@gnu.org, > eller.helmut@gmail.com > From: Dmitry Gutov > Date: Mon, 11 May 2015 23:24:10 +0300 > > On 05/11/2015 05:56 PM, Eli Zaretskii wrote: > > > Making etags recognize them is almost trivial. > > cl-defstruct accessors and predicates? I wouldn't say it's trivial, but > it should be straightforward to implement. In Elisp, at least. In C, > it's bound to be an order of magnitude longer. I don't see the difficulty. Can you explain why you think it's more than a few lines of code needed to produce the tags for accessors and predicates "out of thin air", given just the name of the defstruct, immediately after we produce the tag for the defstruct itself? > > The question is, do we want such ad-hocery in etags.c? > > I guess not, but that's the point: within the restrictions imposed by > etags's design and common sense, you're not going to write an indexer > that takes into account the many different ways Elisp can define > functions implicitly. If we decide that's what we want, then why won't we write that? The number of constructs that need to be handled might be large, but it's finite.