[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: Sun, 26 Jul 2015 16:50:43 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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.

reply via email to

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