From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] emacs-26 b1aaa72: Improve documentation of Xref Date: Mon, 12 Mar 2018 22:34:10 +0200 Message-ID: References: <20180311173926.29923.58430@vcs0.savannah.gnu.org> <20180311173928.14DD220B54@vcs0.savannah.gnu.org> <83o9jts2jj.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1520887271 8014 195.159.176.226 (12 Mar 2018 20:41:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Mar 2018 20:41:11 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 12 21:41:06 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evUFl-0001wa-6E for ged-emacs-devel@m.gmane.org; Mon, 12 Mar 2018 21:41:05 +0100 Original-Received: from localhost ([::1]:34581 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evUHo-0002XZ-8E for ged-emacs-devel@m.gmane.org; Mon, 12 Mar 2018 16:43:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46229) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evU9D-0002RH-C1 for emacs-devel@gnu.org; Mon, 12 Mar 2018 16:34:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1evU99-0003Oi-TY for emacs-devel@gnu.org; Mon, 12 Mar 2018 16:34:19 -0400 Original-Received: from mail-wr0-x22d.google.com ([2a00:1450:400c:c0c::22d]:39388) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1evU99-0003OK-MP; Mon, 12 Mar 2018 16:34:15 -0400 Original-Received: by mail-wr0-x22d.google.com with SMTP id r66so9456820wrb.6; Mon, 12 Mar 2018 13:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WBVvqggsY+FT/SQXlVnzXSPjQz5GHaDwQadNhNgrC5A=; b=cn1L6dEOc3tcnytrrUDVsadUZmzz9agV6ImNTycn/O9BGIhuTCSbkHF2d4JnO9di5R HCZTdRMDFU32JyE1CzKD7qxNZJx/FdGKpXO4KYthRPV4q9KOAWl7C9Ki2MBN/BLkMUYF YRvckSjTFZ/l2ruC8rU9nVOqRkW/qQephdCmz2p2WJNp8YR1091Plwjh+0GCMYZUinfi P38a15N3ZwyH/2vV/RQTGG3Jj91qdkKUHw8E+Nf4IMwHM7/Q8h6GuA+kjg3kAchJbCUP C4kYC2EgvDcfrnCqHcWli7GpfVsV+CSW01VjOOHzvOuYvDV0rhOj0enob6sW/USIGrKQ uieg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WBVvqggsY+FT/SQXlVnzXSPjQz5GHaDwQadNhNgrC5A=; b=hXN9Renor+gTEqxOUd0V4FQ9XiFOLqBlMqJwmgUNPlEc+gkIaCpul25a5Ea7UnFYyc JJvPzKdoQWqC+gj5RxVBwbEGB6YVvBjUXEiVEhNaaEOunJB93uLeyx2/jf2IyTEVqOZr i/xS7bhDqpyh0iJujgxPqNOihguELH24O2ukZ+6VM/7dq4OqV7HkzowRlulP64u/FI4W TtDbODIROJtQbVC3QXltFTdzVYLZt7p9Gk8Z0V3jgW6gC8cMwIGo375MeJdnwszDyRl6 KL7Os5V6bh7THfRgr22i6mds5XPtVMPpZd1IGPc+s5+TYDTp6qZXTqIdKtRlaOtJome/ GMqw== X-Gm-Message-State: AElRT7Fqjx8zWMmaWRwp7NZFbZd5Oxilq/lhfFz9WmhWbmGELY6i9l9K wKU+f0AgIa6wgZMI9ZbBCsPD3UiG X-Google-Smtp-Source: AG47ELvlO+8hdPC334+zCu1xXB6rzpPJqo7ow/KcoqBX3ZjS/zKWnKt6AHVGnsh1zHjtKDuAgMWO/A== X-Received: by 10.223.174.247 with SMTP id y110mr7438387wrc.68.1520886854165; Mon, 12 Mar 2018 13:34:14 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id v17sm8058796wrd.5.2018.03.12.13.34.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 13:34:12 -0700 (PDT) In-Reply-To: <83o9jts2jj.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:223658 Archived-At: On 3/12/18 6:04 PM, Eli Zaretskii wrote: > This is not about fairness at all, and I'm surprised, to say the > least, that you judge the text in these terms. Just talking about what impression the wording might leave. Your new update is better, thank you. > This is about describing a command whose only raison d'être is to > provide a "fire escape" when the default method invoked by M-. fails > to find identifiers, because for some reason they are "out of scope" > for that default method. I didn't mean to ascribe any ill intent to the author. >> More importantly, I think the Reddit user's problem (which has probably resulted in this manual update) was that they thought, for some reason, that xref-find-definitions will always use the tags table. And that them visiting it should affect what xref-find-definitions finds. > > No, I wrote that because it took me some time to find this command, > although I vaguely remembered something like that should be possible. Still, there is that scenario from Reddit: "M-. (bound to xref-find-definitions) can't find any definitions. I visit-tags-file, set tags-file-name and tags-table-list manaully, generated the file with etags and ctags, everything. No luck" Basically, there was no reason to expect navigation to those symbols to work, except that the user had created and visited a tags table containing them. So I think the surprise really was that M-. didn't use the current tags table. >> So if there's some place in the manual that leaves them with that impression, I think it should be updated. > > Feel free to point out such place(s) if you find them. Upon re-reading, I think the manual is indeed pretty clear. And we can ascribe the problem mostly to old habits. > Irrelevant. Once again, this command is only for when M-. fails to > find identifiers, something that shouldn't happen with those more > powerful facilities. Nothing is perfect, and I'm sure there will be cases when a user sees a search fail using one of these more advanced systems. The right course of action there would be to refine their configuration and/or report bugs to appropriate places, and only then maybe try etags (which could still produce worse results). Anyway, I don't have any significant improvements to suggest over the current wording, in this regard. > Thanks, but I see no reason to cloud the issue by refraining from > clearly identifying the situation where this command could be useful. > So I changed the text to make it more accurate, in the hope that it > will no longer lend itself to interpretation that prompted your > reaction. It's better, thank you. Also after re-reading, I see some duplication with what's been said before about how a backend can implement its capabilities in different ways ("built-in means for looking up"), that first item already lists the disadvantages. BTW, you mentioned the auto-loaded functions in the new description of xref-etags-mode, but not in the aforementioned section above, which is arguably more important. Anyway, these are minor things, and I don't have any concrete proposals here.