Re: xref and leaving "temporary" buffers open

[martin rudalics <rudalics@gmx.at>]

 > N > 1 won't help too much. I'm talking about a situation like
 > xref-find-references followed by xref-query-replace. It already gives
 > a performance hit (if there are matches in a lot of different
 > files). And xref-find-references only opens each buffer once already.

I'm interested in finding a proper solution of eldoc for C files.  The
current ones are either based on using the preprocessor (which sucks
IMHO) or tags (which I'd prefer).  In the latter case you have to visit
the file referenced by the tag, go to the reference's target and look at
the function's signature.  After that, the corresponding buffer is
usually left open so using that functionality will leave lots of such
buffers around.

N > 1 means that such a buffer has been visited at least twice so
chances are that it will be visited again in the near future and it
might make sense to keep it around for some time.

 > What kind of cache?

The "cache" would consist of the buffers exclusively visited by the
application (xref, eldoc, ...) in the background.

 >> [Automatic reverting] should be made customizable.
 >

 > I suppose a user option might govern whether xref will prompt before
 > reverting. But then, will it prompt for each file? There might be a
 > lot.

That's easy.  Add an option for each reasonable way to handle this and
time will tell.

 >> 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.
 >
 > You might want to elaborate. This seems to go further than my suggestion.

Buffer are eventually killed explicitly or cleaned up in some way.  In
the second case we have to know whether the buffer was visited by the
user (so a flag is needed anyway) but maybe also whether an application
might be interested in keeping the buffer around for some time more.  So
the clean-up routine would query any application that loaded this buffer
in the background whether it agrees to have it killed or not.  How this
is implemented is merely a matter of taste.

martin