bug#23179: 25.0.92; Restore `M-,' to continue etags search

[Anders Lindgren <andlind@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3589 bytes --]

Hi!

Dmitry:

I think that we would be making a big mistake if we would release Emacs
>> 25 with an "xref" without searching and query-replace, but with key
>> bindings that, for most tags users, break existing use patterns.
>>
>
> As already mentioned, we have multiple solutions for searching, and one
> unified command for query-replace, invoked from the xref buffer.


I have tried all the the functions you have suggested, but I didn't get any
of them to perform like I wanted to. Of course, I didn't have time to dig
into each one of them, so that, for example,
`project-or-external-find-regexp' asked for a new project root directory
and then failed to turn up any matches I put it aside. Likewise, the
"dired" command is not what I was looking for, as it would require me to
mark a number of directories manually before starting.



> Today, many people use "tags" as a simple project file. They don't want
>> to redo this process with another tool ("project") and a dired approach
>> might not match a project layout at all.
>>
>
> project-or-external-find-regexp will take the tags files into account, as
> long as the current major mode hasn't overridden
> project-vc-external-roots-function, or the current project implementation
> hasn't overridden project-vc-external-roots-function.
>
> "redo this process"? Which one?


The process of deciding which files and directories should be included in a
"project". If you use TAGS, you typically do that from an external script
cherry-picking directories and files. You don't want to do that a second
time using some other kind of project manager.



> Maybe I'm being naive, but a tags file (and presumably all other xref
>> backends) must represent a list of files. A free text search and
>> query-replace across those files would be very straight forward to
>> specify, wouldn't it?
>>
>
> An xref backend aims to represent the current coding environment; it could
> combine the source files in the current project, the library files external
> to the project (which could be compiled, zipped, etc), the information
> available in the currently running REPL.
>
> Yes, there probably is a list of files in there a backend could search,
> but it should be specified better than that. Search only inside source
> code, but not documentation, resources, etc? Including any external files
> that do not belong to this project (try imagining a different xref backend
> for C code; it would probably include the installed libraries)?
>
> And again, what do you see as the main advantage of the new command over
> project-or-external-find-regexp?


The advantage over `tags-search' (which I use today) is that I would be
able to use another, more powerful, underlying database. E.g. TAGS does not
manage references to objects whereas systems like "kythe" does.

Apart from that, I rather like the way etags handles search and query
replace -- incrementally and without opening a UI window.


I have given this some thought -- if we decide to really do make a
>> change, maybe we should try to make the xref search command more
>> isearch-like, so that a user could be able to continue an xref search
>> using `C-s' rather than `M-,'.
>>
>
> That doesn't sound clear to me at all. You mean pressing C-s in an xref
> buffer? The place where you can currently use `n', `p', or `,' and `.'?
>
> If you mean in a source buffer, what about next-error and previous-error?
>

I mean the source buffer. Yes, `next-error' is a good candidate. (It's key
binding is somewhat clumsy though, if you need to skip past several
matches.)

    -- Anders

[-- Attachment #2: Type: text/html, Size: 5711 bytes --]