Re: xref and leaving "temporary" buffers open

[martin rudalics <rudalics@gmx.at>]

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

I have thought about this before and am quite sure it's needed.  I don't
want to see such buffers in the buffer list and don't want to
accidentally switch to them.  Actually, it's what keeping me to use the
preprocessor solution at the moment.

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

In the eldoc case this might happen as well.  Over the time buffers pile
up.  And I practically never want to switch to them (which is the only
detail I can supply so far).

 > 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?

All file visiting functions must be aware of it and take it out.  As far
as implementation is concerned we have the usual two choices: Pass an
extra argument (clean but costly) or bind some variable around the calls
that visit the file in the background which is probably the way to go.

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

The "*every* reasonable way" solution applies only where such
customizations are cheap to implement and the behavior is not easily
predictable.  As fas as querying the user for whether to revert buffers
I see no problem in doing that.  Personally, I'd never opt for a
solution where I'm asked for each file individually.  But the options
"never auto-revert", "always auto-revert without asking" and "if at
least one file is stale ask whether to auto-revert all" seem all pretty
reasonable to me and I would probably try them out.

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

OK with me.  My main concern is that such buffers don't show up in my
buffer lists and so one flag is sufficient.

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

The least recently accessed ones, I suppose.  So somewhere we might want
to maintain a timestamp of the least recently background access of these
buffers.

martin