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: Generalizing find-definition Date: Tue, 04 Nov 2014 17:13:42 -0600 Message-ID: <85ppd27e55.fsf@stephe-leake.org> References: <20141102151524.0d9c665c@forcix> <20141102172944.0f7944e3@forcix> <20141103084433.12117c03@forcix> <20141103192853.2702fe7a@forcix> <20141103215526.28edeb27@forcix> <85egtjrpa9.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415142858 22150 80.91.229.3 (4 Nov 2014 23:14:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2014 23:14:18 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 05 00:14:11 2014 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 1XlnIh-0002QH-9k for ged-emacs-devel@m.gmane.org; Wed, 05 Nov 2014 00:14:11 +0100 Original-Received: from localhost ([::1]:43388 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlnIg-0005Lu-Me for ged-emacs-devel@m.gmane.org; Tue, 04 Nov 2014 18:14:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlnIL-0005JF-Ky for emacs-devel@gnu.org; Tue, 04 Nov 2014 18:13:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlnIF-0007PZ-MW for emacs-devel@gnu.org; Tue, 04 Nov 2014 18:13:49 -0500 Original-Received: from dnvrco-outbound-snat.email.rr.com ([107.14.73.225]:8520 helo=dnvrco-oedge-vip.email.rr.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlnIF-0007P1-EY for emacs-devel@gnu.org; Tue, 04 Nov 2014 18:13:43 -0500 Original-Received: from [70.94.38.149] ([70.94.38.149:49448] helo=TAKVER) by dnvrco-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 54/A6-25796-6AD59545; Tue, 04 Nov 2014 23:13:42 +0000 In-Reply-To: (Stefan Monnier's message of "Tue, 04 Nov 2014 13:12:26 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (windows-nt) X-RR-Connecting-IP: 107.14.64.118:25 X-Authority-Analysis: v=2.1 cv=YuWBRuoX c=1 sm=1 tr=0 a=AppmJ/7ZOOFWL/q6u6u93g==:117 a=AppmJ/7ZOOFWL/q6u6u93g==:17 a=ayC55rCoAAAA:8 a=fNEgcOh0sVsA:10 a=9i_RQKNPAAAA:8 a=zQVqd-gIuWmHOgOv3X0A:9 a=yz6mKL8LJl7nNn2l:21 a=60HcBZ4OpLGFrDcw:21 X-Cloudmark-Score: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 107.14.73.225 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:176363 Archived-At: Stefan Monnier writes: >> I would also, but I would not expect a generic Emacs function to return >> that. It certainly requires a backend function. > > Agreed. > >> I'm still not clear what 'identifier-at-point' is good for outside "goto >> definition", "show uses", and completion. Since the meaning is highly >> backend specific, I don't see what other parts of Emacs might use it. > > I just know that it's used commonly. Maybe it's always used by > backend-specific code, so it could stay completely in each backend, but > I don't see any reason why we couldn't standardize the name of that > backend function, in case some non-backend specific code wants to > use it. The reason we can't standardize it is that "identifier-at-point" appears to have different meanings/different results in different situations. For "goto definition" and "show uses", ada-mode needs the simple word at point (no dots; 'baz' in the example), together with the file name, line, and column. "ada-identifier-at-point" only returns the simple word, not all the information needed by "goto definition". Python needs the file name, buffer text, line and column; it does not have an implementation of "identifier-at-point", apparently. For "completion", Python also apparently needs the same information as for "goto definition". Ada mode will probably need the same info as for "goto definition" as well. None of these make sense for something called "identifier at point". "xref-info-at-point" might make sense. So without a list of other uses, it's hard to know how to define "identifier-at-point". I grepped thru ada-*.el for "-at-point", and found: ada-case-adjust-at-point Adjust case of the simple word before point according to the casing mode (typically capitalize first letter). Does _not_ call ada-identifier-at-point. "word" is defined by the syntax classes word and symbol. ada-identifier-at-point discussed above (thing-at-point 'symbol) Used to retrieve the simple word for the external xref engine, when in a C++ buffer; same meaning as ada-identifier-at-point. The external xref engine used by ada-mode is multi-lingual (see gpr-query in the ada-mode sources). Note that thing-at-point does _not_ have an option 'identifier. Also note that the meaning of 'symbol is not given anywhere; the docstring for thing-at-point says "see thingatpt.el", but I don't see a definition there. So apparently the definition is "whatever (thing-at-point 'symbol) returns", which is not very helpful. The default implementation of (thing-at-point 'symbol) relies on the word and symbol syntax classes, which is why it works for C++ mode. That won't work for Ada mode, because "*" is an identifier for a function that overrides *. (Hmm, I'm not sure 'symbol works for overloaded C++ operators, now that I think about it). Note that the default implementation can be overridden by setting symbol properties. So we could require a backend to do that to return the above info, so "goto definition" could start by calling (thing-at-point 'symbol). But if we did take that approach, I'd argue it should be (thing-at-point 'xref) instead. So I'm still puzzled as to what other uses "identifier-at-point" might have. If they are all either satisfied by thing-at-point or are strictly back-end-specific, then we don't need anything new. I grep'd thru emacs/lisp/* for "identifier-at-point"; there were _no_ occurrences. I started grep'ing thru emacs/lisp/* for "-at-point". So far I've found (ignoring things that don't return strings): allout-parse-symbol-at-point - appears to be specific to allout highlight-symbol-at-point - uses find-tag-default-as-symbol-regexp, which defaults to word and symbol syntax classes; could be (thing-at-point 'symbol). thing-at-point - used by calc, cmuscheme, others number-at-point - used by calc, defined in thingatpt.el, uses (thing-at-point 'sexp) completion-at-point-functions - bound by functions in semantic, other modes semantic-completion-at-point-function - defaults to semantic-ia-complete-symbol, which uses parse results. I'll call that backend-specific. variable-at-point - used by cus-edit.el, uses word and symbol syntax classes, then does some more checks on whether it is a lisp symbol. could use (thing-at-point 'symbol) ... and I got tired. So far it's either backend or (thing-at-point 'symbol). There are about 1900 matches; that's a lot of information to sort thru. -- -- Stephe