emacs-devel
[Top][All Lists]
Advanced

[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: Eli Zaretskii
Subject: Re: [Emacs-diffs] emacs-25 f8208b6: Document the user-level features of the Xref package
Date: Thu, 21 Jan 2016 22:32:03 +0200

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Thu, 21 Jan 2016 23:10:52 +0300
> 
> On 01/21/2016 11:02 PM, Eli Zaretskii wrote:
> 
> >> So really want some clear justification, rather than "etags has command
> >> that does this", and "a user could want this". Without the
> >> justification, it would be hard to document the new command anyway.
> >
> > Same justification as for Dired's command you just coded.  Except that
> > in this case, I want to search and/or replace in files that belong to
> > some coherent group that is not a directory hierarchy.
> 
> 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.

> 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.

> >>>> How about xref-query-replace-in-matches?
> >>>
> >>> Fine with me.
> >>
> >> You'd agree that tags-query-replace doesn't require a direct replacement
> >> then?
> >
> > I thought that was what xref-query-replace-in-matches will do.
> 
> 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.



reply via email to

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