[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: Sat, 25 Jul 2015 17:44:06 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

On 07/25/2015 05:12 PM, martin rudalics wrote:

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.

A distinction between loaded and open buffers might help with that as well.

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.

That may be useful for your eldoc problem, but not so much for xref. In the latter case, the issue is not of opening a particular buffer many times, but of opening many buffers 2 or 3 times.

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

A cache is a set of buffers. Okay. How is it implemented? Does switch-to-buffer know they're in the cache? Does it take them out of the cache?

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

If I add an option for *every* reasonable way to handle this (which is already a tall order), what could time tell afterwards?

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.

Flag - yes.

I think a list of applications is going too far. As long as the cleanup is only performed when Emacs is idle (and has been idle for a while, probably), I think we could could on those applications to reopen buffers as needed. For special faces, we could have a second flag, "do not clean up".

Whether doing cleanup is at all necessary is a matter of opinion, but I guess it might be useful to conserve memory. Maybe that subsystem could be smart enough to only trigger cleanup when the buffers exceed a certain amount of memory, and tries to kill the oldest opened buffers first.

reply via email to

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