emacs-devel
[Top][All Lists]
Advanced

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

Re: xref and leaving "temporary" buffers open


From: martin rudalics
Subject: Re: xref and leaving "temporary" buffers open
Date: Sun, 26 Jul 2015 13:27:53 +0200

> How about this:
>
> (defvar-local buffer-hidden nil
>    "When non-nil, this buffer is not returned by `buffer-list',
> unless passed a non-nil INCLUDE-HIDDEN argument.")

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

> (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.

> (defun buffer-list (&optional frame include-hidden)

Good.  Maybe the second argument could be used to not include buffers
starting with a space either.

> (defvar find-file-hidden nil
>    "When non-nil, new file buffers are marked as hidden.
> `find-file-noselect', when creating a new buffer, will set
> `buffer-hidden' to t, and `buffer-hidden-last-access' to the
> current time.
> When it's nil, `find-file-noselect' will set `buffer-hidden' and
> `buffer-hidden-last-accessed' to nil in the buffer it returns.")

Good.  This should be the only hairy part to implement.

> `find-file-noselect' might also become a problem with large amounts of
> hidden buffers, because `find-buffer-visiting' iterates through all
> buffers (and thus is O(N)). Although we should see whether it's an
> actual problem in practice.

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

> "never auto-revert" sounds like "always ask", but without the option
> "yes", because xref should abort in this case rather than return wrong
> results,

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?

> The time when `find-file-noselect' was last called seems like a good
> approximation of the most recent access time.

Agreed.

martin



reply via email to

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