From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] emacs-26 b1aaa72: Improve documentation of Xref Date: Mon, 12 Mar 2018 18:04:48 +0200 Message-ID: <83o9jts2jj.fsf@gnu.org> References: <20180311173926.29923.58430@vcs0.savannah.gnu.org> <20180311173928.14DD220B54@vcs0.savannah.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1520871535 12908 195.159.176.226 (12 Mar 2018 16:18:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Mar 2018 16:18:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 12 17:18:50 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 1evQ9y-0003Dd-Lr for ged-emacs-devel@m.gmane.org; Mon, 12 Mar 2018 17:18:50 +0100 Original-Received: from localhost ([::1]:33018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evQC1-0004UG-Iq for ged-emacs-devel@m.gmane.org; Mon, 12 Mar 2018 12:20:57 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evPwM-00084E-Dr for emacs-devel@gnu.org; Mon, 12 Mar 2018 12:04:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1evPwJ-00047f-6M for emacs-devel@gnu.org; Mon, 12 Mar 2018 12:04:46 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60737) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evPwJ-00047b-1s; Mon, 12 Mar 2018 12:04:43 -0400 Original-Received: from [176.228.60.248] (port=2780 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1evPwI-0000lo-GT; Mon, 12 Mar 2018 12:04:42 -0400 In-reply-to: (message from Dmitry Gutov on Mon, 12 Mar 2018 01:15:47 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:223643 Archived-At: > From: Dmitry Gutov > Date: Mon, 12 Mar 2018 01:15:47 +0200 > > I think that's unfair to all the non-etags Xref backends, both built-in and third-party ones. > > "Some ... might fail to find", "to find more indentifiers" imply that etags always has a bigger and more comprehensive index. Which is not entirely true even for the emacs-lisp-mode xref backend. For instance, it will navigate to the functions defined inside any of the ELPA packages the user has installed. For the etags backend to index them, the user has to know to create a tags table there and visit it, which is not something many of users tend to do. This is not about fairness at all, and I'm surprised, to say the least, that you judge the text in these terms. 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. > 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. > 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. > Note that even if the current xref backend were using a system that has an all-around more comprehensive index (like GNU Global, or one of the LSP servers, etc), the user would still have a problem if they expected M-x visit-tags-table to update that index. Irrelevant. Once again, this command is only for when M-. fails to find identifiers, something that shouldn't happen with those more powerful facilities. > So how about something like this: > > Some major modes install @code{xref} support facilities that use a > different index than the current tags table. For example, in Emacs > Lisp mode (@pxref{Lisp Eval}) @kbd{M-.} will by default search among the > functions and variables from Lisp packages that are loaded into the > current Emacs session. To consult the tags table instead, turn on the Xref > Etags minor mode with @address@hidden xref-etags-mode}}. This command > forces @code{xref} to use the @code{etags} backend (@pxref{Xref}). > (For this to work, you should first run @command{etags} to create the > tags table, see @ref{Create Tags Table}.) 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.