From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: xref and leaving "temporary" buffers open Date: Sat, 25 Jul 2015 18:09:33 +0300 Message-ID: <55B3A6AD.6030008@yandex.ru> References: <55B2DC8F.3050305@yandex.ru> <83vbd81yti.fsf@gnu.org> <55B38E95.5060902@yandex.ru> <83h9os1gbx.fsf@gnu.org> <55B39C3A.9070107@yandex.ru> <83egjw1ez7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1437836998 8488 80.91.229.3 (25 Jul 2015 15:09:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jul 2015 15:09:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 25 17:09:51 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZJ15A-0007wp-L1 for ged-emacs-devel@m.gmane.org; Sat, 25 Jul 2015 17:09:48 +0200 Original-Received: from localhost ([::1]:48322 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJ159-0003U2-SX for ged-emacs-devel@m.gmane.org; Sat, 25 Jul 2015 11:09:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJ155-0003Sl-LB for emacs-devel@gnu.org; Sat, 25 Jul 2015 11:09:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJ151-0007xz-J0 for emacs-devel@gnu.org; Sat, 25 Jul 2015 11:09:43 -0400 Original-Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:36364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJ151-0007xg-Bq; Sat, 25 Jul 2015 11:09:39 -0400 Original-Received: by wicgb10 with SMTP id gb10so60294956wic.1; Sat, 25 Jul 2015 08:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=S6HNSC72EBXznwoZc8DR8zzpTuqc6OFUSEZyMsAyCvA=; b=b2oq5331do9wD4r+WEiQ877lj6cfAcr4PHdVV2qtu1b2YwZwM8LBIx5FtPD8oR+2xJ IA06o0wpSVY2dSnPULitSiq4O52dNqLmqDsIBnrEdqif+dzgFf2dIL9u7JNAbpF2Dc6e XmWyOVvzUjsZThX45sOPOv2Bex1UtOJpJ3mZdYjRN3f8VaRyT7vfP0UrKDEl/ZA7OZvT +g2fTEIf6UDJZSgdpDRbRh+/cC6UMpEop87VumR/6/tZStozMR+OTzatDpGhJvxH+llN 77VS1HX8jM9KiUsQmOiGX//HLFrlU8JMMH0tKbQ+ehzm73YWWxGYJLFWj8jeeYhFO9tU Ks0g== X-Received: by 10.194.121.100 with SMTP id lj4mr37381480wjb.104.1437836978622; Sat, 25 Jul 2015 08:09:38 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id ez4sm3691900wid.14.2015.07.25.08.09.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Jul 2015 08:09:37 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <83egjw1ez7.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188071 Archived-At: 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.