[Top][All Lists]

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

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

From: Anders Lindgren
Subject: bug#23179: 25.0.92; Restore `M-,' to continue etags search
Date: Mon, 4 Apr 2016 10:21:31 +0200



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

reply via email to

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