Re: xref and leaving "temporary" buffers open

[Dmitry Gutov]

On 07/25/2015 04:47 PM, Stephen Leake wrote:

> Better for xref to cache the info it gathered from the buffer (assuming
> that's significantly smaller, and faster to access, than the buffer).

Whatever the format of that info, it probably won't work between 
invocations of xref commands with slightly different inputs.

And xref-query-replace is currently implemented via the same mechanism 
as what query-replace-regexp uses, which means it needs to visit every 
buffer in a normal way anyway.

> > This should be made customizable.
>
> Yes. Also provide flush- or refresh-cache functions.

These seem to be separate issues. We might ask the user whether to 
revert an "open" buffer (not one in the cache).

And regarding refresh-cache, I'd rather each application that needs a 
buffer from the cache reverted only the buffers it needs. Maybe the new 
function that opens and cached that kind of buffers (like 
find-file-in-cache), would even do that automatically.

> One use case would be "goto buffer in project", that completes only on
> buffers visiting files that belong to a project (in the xref "project"
> sense). The buffers could have a property "projects" that was a list of
> some project name/id/root directory.

So far, this could be implemented via an arbitrary buffer-local 
variable. Or just simply looping through (buffer-list) and checking 
buffer-file-name against the project-directories; that should be fast 
enough, with reasonable number of open buffers.

> Another use case (that I've actually implemented differently) is
> deleting all buffers that were fetched by a front end to git as part of
> reviewing a commit (they display old versions of files).

Don't you think vc-revision-other-window provides a reasonable solution, 
by adding a suffix to a buffer's name? If that's not enough (for 
instance, if we want to delete them all later, and matching names to 
.*\.~.+~ is not precise enough, we could use a buffer-local var as well).

> Functions for deleting some buffers based on such buffer properties
> would also be useful. In the projects case, the buffer would not
> actually be deleted until there was only one project property left.

What if the user opened it using switch-to-buffer, not using "goto 
buffer in project"? Then it wouldn't have this property set, right?