unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: Re: [Emacs-diffs] emacs-26 b1aaa72: Improve documentation of Xref
Date: Mon, 12 Mar 2018 01:15:47 +0200	[thread overview]
Message-ID: <bf3f0834-8fb8-1c8a-3c8a-e33b683a3a6f@yandex.ru> (raw)
In-Reply-To: <20180311173928.14DD220B54@vcs0.savannah.gnu.org>

Hi Eli,

On 3/11/18 7:39 PM, Eli Zaretskii wrote:
> branch: emacs-26
> commit b1aaa72df8e0afd8a849aab7525640f1cec66af3
> Author: Eli Zaretskii <eliz@gnu.org>
> Commit: Eli Zaretskii <eliz@gnu.org>

> +@findex xref-etags-mode
> +  Some major modes install @code{xref} support facilities that might
> +fail to find certain identifiers.  For example, in Emacs Lisp mode
> +(@pxref{Lisp Eval}) @kbd{M-.} will by default find only functions and
> +variables from Lisp packages that are loaded into the current Emacs
> +session.  To find more identifiers, turn on the Xref Etags minor mode
> +with @w{@kbd{M-x 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}.)

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.

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.

So if there's some place in the manual that leaves them with that 
impression, I think it should be updated.

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.

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 @w{@kbd{M-x 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}.)

?



       reply	other threads:[~2018-03-11 23:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180311173926.29923.58430@vcs0.savannah.gnu.org>
     [not found] ` <20180311173928.14DD220B54@vcs0.savannah.gnu.org>
2018-03-11 23:15   ` Dmitry Gutov [this message]
2018-03-12 16:04     ` [Emacs-diffs] emacs-26 b1aaa72: Improve documentation of Xref Eli Zaretskii
2018-03-12 20:34       ` Dmitry Gutov
2018-03-12 22:43         ` Stefan Monnier
2018-03-12 23:45           ` Dmitry Gutov
2018-03-13  2:18             ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bf3f0834-8fb8-1c8a-3c8a-e33b683a3a6f@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).