[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 18:09:33 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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.

reply via email to

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