[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: Fri, 22 Jan 2016 00:40:36 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0

On 01/21/2016 11:32 PM, Eli Zaretskii wrote:

Dired's command makes sense: when there's no project, or we want to
search some dirs specifically, we can fire up Dired, select the
directories and files one by one, and do the search.

The same with a backend: it selects the files to search.

We wouldn't want to use a command that searches an arbitrary set of files, which depends only on the mood of the person who wrote a particular backend. Stricter semantics are needed.

Furhermore, Dired's commands we're replacing had default bindings. tags-search only has a menu entry.

When you call xref-find-regexp, you won't get to tell exactly what you
want. So, the command needs to have some useful, clear semantics.

It does.  With the etags backend, the TAGS file tells it to, and the
user controls what goes into that file.  I presume other backends
could do similar stuff.

That doesn't look general enough. What do I write in the docstring? "Searches where the TAGS files tell it to, or does similar stuff"?

xref-query-replace-in-matches will be the new name for the current
xref-query-replace. The changed name should signify that it replaces,
indeed, in the already-present list of matches.

Since you said that having xref-query-replace called almost the same as
tags-query-replace is confusing.

Ah, okay.  That'd be good, but we still should try to find a good xref
replacement for tags-query-replace, IMO.

We should wait for more opinions, then. It won't be hard to add a command like that later.

reply via email to

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