Re: xref and leaving "temporary" buffers open

[Stephen Leake]

martin rudalics <address@hidden> writes:

>> Should we disregard this issue and say that xref doesn't have to close
>> the buffers it needed to open during operation?
>
> I'd try to implement some sort of heuristics, like adding a buffer to
> some sort of a cache only after its file has been visited by an
> application (like xref) at least N times and removing a buffer from that
> cache if it has not been visited by an application (like xref) for at
> least T minutes.

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

>> Another problem with that might be the contents getting out of date:
>>  what if the user doesn't have global-auto-revert-mode on? Then an
>>  xref search might get erroneous results from those buffers. Would it
>>  be allowed to call `revert-buffer' anywhere, as long as the buffer
>>  doesn't have unsaved changes?
>
> This should be made customizable.

Yes. Also provide flush- or refresh-cache functions.

>> Certain other programs might have a project and all its files loaded,
>> but still display only a few of them as the ones the user is editing
>> (probably using tabs). Should Emacs have a similar distinction,
>> between loaded and open buffers?
>
> I think so.  Each buffer should maintain a list of all the applications
> that visited its file and all operations on buffer lists should be aware
> of it.

That makes sense.

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.

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). My current
implementation relies on a list of such buffers maintained by the front
end, but it would be better if there were some standard tag on the
buffer. I don't like to close such buffers immediately after the first
ediff session, because I often want to come back to them for some reason.

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.

-- 
-- Stephe