[Top][All Lists]

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

Re: xref and leaving "temporary" buffers open

From: Dmitry Gutov
Subject: Re: xref and leaving "temporary" buffers open
Date: Sat, 25 Jul 2015 18:51:57 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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?

reply via email to

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