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: [Emacs-diffs] master d7df36e: Rewrite elisp--xref-find-definitions to handle many more cases; add tests. Date: Wed, 12 Aug 2015 02:40:31 -0500 Message-ID: <86y4hhvtsg.fsf@stephe-leake.org> References: <20150811025613.30799.89490@vcs.savannah.gnu.org> <55CA1F30.6050402@yandex.ru> <86fv3pxv0u.fsf@stephe-leake.org> <55CA8C5B.4070409@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439365269 22528 80.91.229.3 (12 Aug 2015 07:41:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Aug 2015 07:41:09 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 12 09:40:59 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 1ZPQeg-0008WG-0W for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2015 09:40:58 +0200 Original-Received: from localhost ([::1]:37335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPQef-0007PL-GK for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2015 03:40:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPQeb-0007O0-Gc for emacs-devel@gnu.org; Wed, 12 Aug 2015 03:40:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPQeY-0003Rw-7w for emacs-devel@gnu.org; Wed, 12 Aug 2015 03:40:53 -0400 Original-Received: from gproxy1-pub.mail.unifiedlayer.com ([69.89.25.95]:44789) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZPQeY-0003RR-08 for emacs-devel@gnu.org; Wed, 12 Aug 2015 03:40:50 -0400 Original-Received: (qmail 7283 invoked by uid 0); 12 Aug 2015 07:40:43 -0000 Original-Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 12 Aug 2015 07:40:43 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by CMOut01 with id 3jgb1r00p2UdiVW01jgeM0; Wed, 12 Aug 2015 01:40:42 -0600 X-Authority-Analysis: v=2.1 cv=NJxGpSKg 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=y7kgw_RnJtkA:10 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=uRRa74qj2VoA:10 a=vaJtXVxTAAAA:8 a=GmnYYMV-v7KdZ2jCKpcA:9 Original-Received: from [76.218.37.33] (port=52574 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZPQeK-0006c3-Ck for emacs-devel@gnu.org; Wed, 12 Aug 2015 01:40:36 -0600 In-Reply-To: <55CA8C5B.4070409@yandex.ru> (Dmitry Gutov's message of "Wed, 12 Aug 2015 02:59:23 +0300") 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: 69.89.25.95 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:188747 Archived-At: Dmitry Gutov writes: > On 08/12/2015 02:30 AM, Stephen Leake wrote: > >>> How come you saw fit to undo the tweaks that I've added over time? >> >> Because they got in the way of some of my uses of xref-find-definitions. > > At least a question would've been nice. > >> In general, rather than using similar heuristics in the low level code, >> we should be adding hints from the source being searched, and/or the >> user. > > In general, elisp-xref doesn't open the source files. When used with > xref-find-apropos, that was rather slow. > >> For example, one heuristic returned only the function when there are >> both function and feature with the same name. But there are times when I >> want to see both, or one or the other. > > If the feature and the function have the same name, idiomatically, > they will always be in the same file. I was going to say "not guarranteed", but that is a style we strongly encourage, so I think it is reasonable to rely on it. > Why wouldn't you want to jump to > the function? > I see you're also jumping to the (provide 'xxx) forms. What's the use > in that? I think that's because I was trying to find the closest equivalent to what Ada mode does. In Ada, every file has clear syntax indicating "the start of the file code", and M-. on "with foo;" jumps to that point in foo.ads. (provide 'foo) is the closest thing in elisp syntax. We could jump to the ;;; Code: comment. For a better reason, sometimes it does matter what happens in the file after (provide 'foo), so that's sometimes a useful place to go. > If it's not right, M-< is not too far away (or M->, as per below). and M-. to jump to the function is also not too far away. But even better is the source code info discussed below; if that works, this point is moot. >> So if I'm searching for the >> identifier at point, in code like this: >> >> (dvc-log-edit ...) ;; point on '-l'; show defun >> (require 'dvc-log-edit) ;; point on '-l'; show feature >> >> In both cases, we can easily tell from the source near point what the >> user is searching for. > > Right, it's a good default behavior. But then we'll have to decide how > the user could indicate whether elisp-xref should *not* look at the > context. Currently, C-u only forces the prompt to appear, but the > default value will still use the text properties from the context (if > xref-default-identifier-at-point includes them). C-u should strip the text properties. >> Yes. But I thought the heuristic the previous code used was: "if there >> is both a variable and a function by the same name, _assume_ they are >> located in the same place, so only return the function". That assumption >> is broken for some of my code, and I assume in many others as well. >> >> However, you point out later that you used (memq sym minor-mode-list) to >> determine if this is from define-minor-mode. >> >> I didn't realize why that was there when reading the code. >> >> So I'll put that back, with a comment this time :). > > There was a comment: "Don't show minor modes twice". I thought it > explained the purpose of (not (and (fboundp sym) (memq sym > minor-mode-list))) clearly enough. Not for me, obviously. I will ask first about code I don't understand in the future. Did you find my comments clear enough? -- -- Stephe