Re: xref and leaving "temporary" buffers open

[martin rudalics]

> 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