From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] emacs-25 f8208b6: Document the user-level features of the Xref package Date: Tue, 19 Jan 2016 01:18:20 +0300 Message-ID: <569D64AC.1060606@yandex.ru> References: <20160109191428.26341.44105@vcs.savannah.gnu.org> <5691C9D2.7080905@yandex.ru> <83egdpmo1j.fsf@gnu.org> <56929D6F.2050508@yandex.ru> <834melmfa4.fsf@gnu.org> <5692B1E0.8010100@yandex.ru> <831t9pma4e.fsf@gnu.org> <5693FDFA.2070607@yandex.ru> <83ziwbkj5l.fsf@gnu.org> <5694055E.6050201@yandex.ru> <83si1udcaz.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453155517 20780 80.91.229.3 (18 Jan 2016 22:18:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jan 2016 22:18:37 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 18 23:18:37 2016 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 1aLI8C-00071p-95 for ged-emacs-devel@m.gmane.org; Mon, 18 Jan 2016 23:18:36 +0100 Original-Received: from localhost ([::1]:34031 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLI88-0006B0-6F for ged-emacs-devel@m.gmane.org; Mon, 18 Jan 2016 17:18:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLI84-0006Aq-Qs for emacs-devel@gnu.org; Mon, 18 Jan 2016 17:18:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLI7z-0005Nh-QN for emacs-devel@gnu.org; Mon, 18 Jan 2016 17:18:28 -0500 Original-Received: from mail-lb0-x22c.google.com ([2a00:1450:4010:c04::22c]:35731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLI7z-0005Nd-Hi; Mon, 18 Jan 2016 17:18:23 -0500 Original-Received: by mail-lb0-x22c.google.com with SMTP id bc4so352950395lbc.2; Mon, 18 Jan 2016 14:18:23 -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=FX1tg2dXjsSTHbmkFcOmeaV0pUcO0b9Om29jUfu4N3E=; b=UcnLipdlnzSDoKmSZIIbnEnv6Q5Aqd3bGbJqxXsDS3UgdgXIagEp+xoAgX2ORfQd4y eK0MYHbiTdPtNQIxhFygdrcHuuctWAgjX+Z+nYGFkUBcMFMRBtRn8YYyTwHKstyM0VYm aL8PospElA8tkw9NpTnLXju9y+GfwKZ2Ku3JzdZQVdNLgFN6/FZKbWuIPNBtdh3kwrwJ E+yGZvYwQZq9Djxlcoy5HAzrSMyAj1i3BaQ0c2XVLTOl8364QA2Puo4BCZJ61uo+F8Y0 pt62KRFMHQFl2Q0/hGoTr0QoepJG/UM9KaMkI+uggRjO53pAUFtF7XF0FOMQji3LfYCv lnUg== 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=FX1tg2dXjsSTHbmkFcOmeaV0pUcO0b9Om29jUfu4N3E=; b=YSBv7e8kUHhNx4TQY81hW4D4ozRhOG/EdI71JOGqbNC+A3Zfx8PDGquIUdj7xzzkAT l+Q57mCgj+gBfoZfFEWyDbKriy+/DF3f6ufO5x94Z/DUOxubNiHZ2gO7ua0xpd/8qwyd I1Kc//ia20mtr8avgAh/vE84SDlXI6KGub3fnCFFlVUY6iw+foWXez0MGaZe8db0tkJY 7xC5qvmnFECYithUsYJT/h4iAVnrKLPpbjHkkn3fcJODGW95f5MaNeEC7bmnn7u/d7aD fzjwMXz/M/ygjseWKE9S8CjkI7u33gyGmR2JPC60m+0d43lakKnz2qOWQchX5BFb9BCk rTQw== X-Gm-Message-State: ALoCoQmfzSQKOi6VxsKyvWSv82obCKcr2S4kMD3l29A5nEkFNwfiffMOQQB3+HGbdUrZ683v6/Ddxa8JaUytp29IySu8N+WaXQ== X-Received: by 10.112.168.5 with SMTP id zs5mr9706838lbb.56.1453155502728; Mon, 18 Jan 2016 14:18:22 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id nv8sm3456009lbb.7.2016.01.18.14.18.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 14:18:21 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Thunderbird/43.0 In-Reply-To: <83si1udcaz.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::22c 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:198306 Archived-At: On 01/18/2016 08:31 PM, Eli Zaretskii wrote: > I tried to improve the manual according to your comments, please have Thank you, Eli. I think it's good now, but see a couple of nits below. > a look. (I suggest to read the Info manual, not look at the diffs.) I did that too, after some usual (for me) flailing around, to find the needed node in the manual. The diff turned out to be more useful, though, because I was able to quickly see what was removed, and what was changed. The promised nits: > If there is a tags table loaded, this command can use it to +generate completion candidates more intelligently. That implies that we have some "dumber" completion sources than etags in Emacs. I don't think we do, currently. tags-completion-at-point-function is the default value of completion-at-point-functions, and we use it as the last resort if the major mode (or any minor mode) don't provide any specialized completion functions. Then, if no tags table is loaded, we don't provide any completions at all, not even stupid ones. I'd suggest to simply remove "more intelligently". > + A @dfn{tag} is a synonym for identifier reference. @xref{Xref}. Maybe that's technically true, but as employed by Emacs usually, tags are elements of TAGS file, generated by the 'etags' program, and they only reference identifier definitions. This is the reason we had to resort to other means to implement xref-find-references anyway. And in CEDET, there is a notion of "current tag", which is the function definition around point. Not variable reference or the method called at point, as one might expect to be the default input for `semantic-symref'. Call it an "identifier definition reference", maybe? Or "identifier definition", or "definition reference".