From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#22692: 25.0.91; xref-find-definitions fails to prompt Date: Fri, 19 Feb 2016 15:43:57 +0200 Message-ID: <56C71C1D.8010502@yandex.ru> References: <23698.1455674128@allegro.localdomain> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1455889890 3325 80.91.229.3 (19 Feb 2016 13:51:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Feb 2016 13:51:30 +0000 (UTC) Cc: 22692@debbugs.gnu.org To: Mike Kupfer Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 19 14:51:20 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1aWlSi-0005tu-Ax for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Feb 2016 14:51:12 +0100 Original-Received: from localhost ([::1]:52482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWlSh-0006cZ-OC for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Feb 2016 08:51:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60553) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWlMp-0004gJ-AL for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2016 08:45:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWlMk-0004wj-AH for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2016 08:45:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36476) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWlMk-0004wf-7F for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2016 08:45:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aWlMj-0000S1-RD for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2016 08:45:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Feb 2016 13:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22692 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22692-submit@debbugs.gnu.org id=B22692.14558894481659 (code B ref 22692); Fri, 19 Feb 2016 13:45:01 +0000 Original-Received: (at 22692) by debbugs.gnu.org; 19 Feb 2016 13:44:08 +0000 Original-Received: from localhost ([127.0.0.1]:33603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aWlLr-0000Qh-Ua for submit@debbugs.gnu.org; Fri, 19 Feb 2016 08:44:08 -0500 Original-Received: from mail-wm0-f50.google.com ([74.125.82.50]:36673) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aWlLp-0000Q5-OR for 22692@debbugs.gnu.org; Fri, 19 Feb 2016 08:44:06 -0500 Original-Received: by mail-wm0-f50.google.com with SMTP id g62so76850678wme.1 for <22692@debbugs.gnu.org>; Fri, 19 Feb 2016 05:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=NzzsHsMeMbzF0/GyBg93uuhxC0CSyulzztBzOe0A3CE=; b=CkmyVa3O9HG1ZgPbP8if5lMjPo9KPNFdiamK2gr779TDHylBsMndC5RpqCig8AQyl3 2DyJRhePx6VzV2Ygk73JBubEO87RbRSoj7HQ5UDLxfI255tRrb/hPSuwQWUVrrtDxcD9 Q8HI8X5TlEIe4p/DPqacKeWujmKY4lWlrEXp1kgEjo93yT8/fNFSdpI22yg1cmYwx3d0 dh+EbM6qPoBDqS8WNIsUyfc2IdyZIYXmPOgeKyEG+J2FT1yarDBl8vgbUFq62luWlJDe Qslmr5QfZW7y/COxHMQLzCVAavwILo5D7koQF1dtCKDFMtotDHwlxvs6KLdUGLYdtqe7 8Llw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=NzzsHsMeMbzF0/GyBg93uuhxC0CSyulzztBzOe0A3CE=; b=g5JsLfwVa7nVJ0ZLs/BZVXs3NAjsK2C2LyClw/05Hq+0xBsGuAHHuwrIn0isGUlIDe UZ18uI7JceIMe7kiBSaEVsFn/tYfHSBOeG1yxhgNIEZpOQ/F3c+4I7VAQEifyiAKqM1x XsWpSL5Dhisb0sZXJBm/rIRVwaKPe0pjQpXlnLMx+3FD2pC0YoVLoG1M+z2KR+slP6Y9 usqgIGSH3Q3aUBQ2po+arywoFcFDwojmdDMdaBYvetG/CN4NKmQ6X7/K4//tcE/mAgh9 xHxTndLOU8xBRMrHzzYU/jjxkXliOmueEDhLJMBFuz0VHwumSTaOXJOPtkG4PMtw3DUi v41Q== X-Gm-Message-State: AG10YOQF4wvS3C19mmmmlIOXEzfaoy4Ry2LSoTpilR/UYYEQwfcGAcO6h9oAKodrtCWvsg== X-Received: by 10.194.94.40 with SMTP id cz8mr13335637wjb.17.1455889440204; Fri, 19 Feb 2016 05:44:00 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id v22sm7728505wmv.12.2016.02.19.05.43.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Feb 2016 05:43:58 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <23698.1455674128@allegro.localdomain> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:113297 Archived-At: On 02/17/2016 03:55 AM, Mike Kupfer wrote: > The Help string for xref-find-definitions says > >> With prefix argument or when there’s no identifier at point, >> prompt for it. > > I guess you could argue that if point is on a token that's not in the > tags table, it's still on an "identifier". Whatever identifier the backend says is there. Which, in the case of etags, delegates to find-tag--default. Validating identifiers against the tags table is a sensible suggestion, but that might backfire in several scenarios: - What if the tags table only contains fully qualified names? We have multiple ways the backend can match tags, defined by etags-xref-find-definitions-tag-order, which might apply even if the identifier is not literally one of the elements. And I'm not sure performing that matching logic just when the default identifier to use is returned, is a good idea. - Either xref-backend-identifier-at-point impl for etags will have to be able to use different logic based on the command currently being invoked (that doesn't really fit in the current design), or you won't be able to look for e.g. occurrences of the local variable at point (using xref-find-references), because etags doesn't parse local variables. > But "#" is hardly an identifier. Apparently it is, as far as find-tag-default-bounds is concerned. In the following sense: find-tag-default-bounds uses the notion of "symbol" as defined by the current syntax table. If "#" can't be a part of an identifier name in the programming language in question (C, right?), maybe you should request that character's syntax class to be changed to something like "punctuation" there. > Does "valid identifier" mean syntatically correct, or does it mean that > the identifier is in the tags table. Please clarify the documentation. We probably should just remove the word "valid" from there.