Re: xref and leaving "temporary" buffers open

[Dmitry Gutov <dgutov@yandex.ru>]

On 07/25/2015 05:36 PM, Eli Zaretskii wrote:

> Is it ever possible to have a discussion with you without feeling
> castigated for my views and opinions?  You asked for opinions, so
> please accept them benevolently, even if you don't like them.

I'm sorry, it's just I've seen the suggestion to handle every possible 
behavior too many times, from different people in the Emacs community.

What I'm asking is which behavior people here will actually prefer, 
after weighing the tradeoffs. You've written that below, and thank you 
for that.

> My vote is for the default that keeps the buffers.  I see nothing
> wrong with having a lot of buffers in an Emacs session.  Personally, I
> regularly walk through all my buffers and kill those I no longer need,
> because I use desktop.el to restore my sessions, which would otherwise
> grow indefinitely.  It's no big deal.  It is much less of a big deal
> if sessions are not restored.

That's what I'm also inclining towards now. However, the list of buffers 
automatically opened by xref might be too big for you (or me) to clean 
up manually (if you search for occurrences of some common word, for 
example). After that, I'm not sure what a user might do to undo that. 
(mapc #'kill-buffer (buffer-list)) might be the only option.

>> If the buffers are killed, xref-query-replace will need to account for
>> that, and not open too many buffers at the same time.
>
> I don't see why that would be true.  Please elaborate.

To be clear, I mean it'll need not to open all buffers in advance.

At the moment, it opens all files, and puts markers around each match, 
because if there are several matches on the same line, after the 
replacement is performed on the first of them, the rest will become 
"stale", because the recorded column information will become outdated.

In order not to spend too much time on opening buffers in advance, it'll 
need to open only one or two buffers at the same time, before moving to 
the next match to replace. That will increase the performance, as 
perceived by the user.

> You asked for an opinion, that's mine.  IME, good engineering
> anticipates such requests before they are voiced.  If you can only
> resolve a controversy applying your personal preferences, it's a clear
> sign that someone, somewhere will be unhappy about it.

We can't really support *every* preference. And some of them can even be 
incompatible with architectural decisions providing best tradeoffs.

IMO, it's better to decide on the default workflow that we believe to be 
useful to most, and only after that add variations to that behavior.

Ideally, we might even find a solution that satisfies the needs of both 
kinds of users, which would otherwise ask for different behaviors, 
tailored for their needs. In this instance, a "buffer cache" might be 
that solution, if it'll provide both performance benefits of not having 
to open the buffers several times, as well as the clutter management 
benefits, if the buffers are flagged appropriately.