[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] emacs-25 f8208b6: Document the user-level features of

From: Dmitry Gutov
Subject: Re: [Emacs-diffs] emacs-25 f8208b6: Document the user-level features of the Xref package
Date: Thu, 21 Jan 2016 06:28:51 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0

On 01/20/2016 07:43 AM, Eli Zaretskii wrote:

"Xref" is the name of the node, not of the section.  And the node's
name does not mean it describes xref the package; this is user-level
documentation.  If you have a better suggestion for a short name of a
node which aims at describing features most of which have "xref-" in
their names, please tell.

Cross-Referencing? A native speaker might have a better suggestion.

AFAICT, your additions are not directly related to this section; they
are not mentioned in it.

Hmm. When I asked what we needed to obsolete tags-loop-continue, you only mentioned Dired commands.


No, dired-do-find-regexp cannot replace it, because it looks through
all the files in the directory, whereas tags-search looks in the files
recorded in the tags tables.

Ok, dired-do-find-regexp cannot. What about project-or-external-find-regexp?

By default, when the VC project backend is used, and project-vc-external-roots-function is at its default value, project-or-external-find-regexp will search the current project, as well as the directories of the tags tables, if they are outside of it.

Or, in emacs-lisp-mode, it will search the load-path directories.

We should have an xref-based replacement
for tags-search and tags-query-replace, which would similarly search
through the "relevant" files.

tags-query-replace? We have xref-query-replace already, and it's more flexible: depending on which results it's called from, it'll perform replacements in simple regexp matches, or in "smarter" list of references (or other similar kinds of results).

Back to tags-search.

Like described above, we have a command that goes further that it already. So what would be the goal of having xref-find-regexp? Just to tick off a box and simplify updating the manual?

It will require adding a new method to xref backends, with clear semantics and purpose. Backend authors will want to know why they implement it, and why a user might want to use xref-find-regexp, instead of the aforementioned alternative.

Suppose we're in emacs-lisp-mode. What will xref-find-regexp do? Will it search the load-path elements, but skip the current project, however it's defined, if it's not in load-path? Will it only search *.el files inside load-path directories, and ignore files with all other extensions?

(Btw, I think replacing tags-search and tags-query-replace with
commands that start with "project-" is not a good idea, for the same

I definitely never suggested replacing tags-query-replace with project- anything. The new "replace" workflow is two-step: two the search (using some command that creates an xref buffer), then call xref-query-replace.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]