Re: xref and leaving "temporary" buffers open

[Dmitry Gutov]

On 07/26/2015 02:27 PM, martin rudalics wrote:

> Good (if you fix the doc-string).  We should then rewrite and change the
> name of BUFFER_HIDDEN_P to avoid confusions.

Indeed. But the new macro, seem like, should return true for either 
ephemeral or hidden buffers.

>  > (defvar-local buffer-hidden-last-access nil
>  > "The time when this buffer was last accessed.")
>
> Good.  I'm not yet sure whether there could be problems with dead
> buffers but I don't think so.

Dead as a result of the cleanup routine (to be implemented later)? 
Probably, but we can try to minimize the odds of that.

>  > (defun buffer-list (&optional frame include-hidden)
>
> Good.  Maybe the second argument could be used to not include buffers
> starting with a space either.

I don't know about that. Sometimes you really want to switch to one of 
those buffers while debugging. But there shouldn't be anything 
interesting in the proposed hidden file buffers.

>  > (defvar find-file-hidden nil
>  > ...
>
> Good.  This should be the only hairy part to implement.

It doesn't sound too hard. The buffer-list change looks more complicated 
to me, simply because it's in C.

By the way, I wonder if we're going to discourage, or somehow specially 
handle, calling find-file-noselect with RAWFILE t.

> We can always prune the list when it gets too large.

We'll see. There might be performance benefits to keeping it pretty big. 
Computers have a lot of memory nowadays.

> Does this remark only apply to `xref-query-replace'?  For a pure `xref'
> search we should allow stale contents IMHO.  And does xref always check
> the file modification data?  Does it re-run etags?

That depends on the implementation of a particular command. The ones 
that dispatch to etags, will consult the (possibly out-of-date) TAGS 
file, and etags-goto-tag-location will make adjustments.

Same for Elisp xref backend.

However, the search-based commands (find-references, find-matches) might 
require up-to-date contents.

The only sane alternative, I think, is in addition to running Grep 
iterate through all open buffers and `re-search-forward' through them. 
...or only the stale ones? I'm open to further investigation in this 
direction.

But if we augment Grep with re-search in Elisp, it will complicate the 
handling of stale buffers in xref-query-replace. We won't be able to ask 
to revert all stale buffers in advance, because some matches will be 
from stale buffers. And then, some buffers might have further change.

I guess whether we want to go in this direction, depends on whether we 
think re-search-forward's performance is on the same order of magnitude 
as Grep. IOW, whether having lots of stale buffers might incur visible 
performance penalty.