From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: xref and leaving "temporary" buffers open Date: Sat, 25 Jul 2015 18:27:37 +0300 Message-ID: <83bnf01cly.fsf@gnu.org> 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> <55B3A6AD.6030008@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1437838082 24749 80.91.229.3 (25 Jul 2015 15:28:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jul 2015 15:28:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 25 17:27:53 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 1ZJ1Me-0000NK-Ut for ged-emacs-devel@m.gmane.org; Sat, 25 Jul 2015 17:27:53 +0200 Original-Received: from localhost ([::1]:48359 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJ1Me-00073l-61 for ged-emacs-devel@m.gmane.org; Sat, 25 Jul 2015 11:27:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51569) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJ1MS-000738-KE for emacs-devel@gnu.org; Sat, 25 Jul 2015 11:27:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJ1MP-00015z-Am for emacs-devel@gnu.org; Sat, 25 Jul 2015 11:27:40 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:57101) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJ1MP-00015c-2z for emacs-devel@gnu.org; Sat, 25 Jul 2015 11:27:37 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NS100G00TW25000@mtaout25.012.net.il> for emacs-devel@gnu.org; Sat, 25 Jul 2015 18:23:47 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NS100ECQURMIJ40@mtaout25.012.net.il>; Sat, 25 Jul 2015 18:23:47 +0300 (IDT) In-reply-to: <55B3A6AD.6030008@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 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:188072 Archived-At: > From: Dmitry Gutov > Date: Sat, 25 Jul 2015 18:09:33 +0300 > Cc: emacs-devel@gnu.org > > > 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. Then perhaps there should be a command to kill all those buffers created by xref for these purposes. OTOH, look at the example of info.el's info-apropos: it doesn't keep around the Info manuals it visits. So this is also a reasonable behavior we have elsewhere. > 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. If you can identify that now, fine. If not, there's nothing wrong with changing the default later, as long as non-default behavior is available as an option. > 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. Again, if that can be identified, fine. But if not, having several optional behaviors is the Emacs'y way of not forcing users into Procrustean situations.