From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: Occur stack Date: Tue, 21 Jan 2014 10:05:51 +0100 Message-ID: References: <52D6D907.4030702@online.de> <52D8E8CB.5080600@online.de> <87eh45jk5p.fsf@building.gnus.org> <87lhy9zsab.fsf@mail.jurta.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390295184 2790 80.91.229.3 (21 Jan 2014 09:06:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jan 2014 09:06:24 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 21 10:06:29 2014 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 1W5XHv-0002lH-O4 for ged-emacs-devel@m.gmane.org; Tue, 21 Jan 2014 10:06:27 +0100 Original-Received: from localhost ([::1]:56804 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5XHv-00074Q-8q for ged-emacs-devel@m.gmane.org; Tue, 21 Jan 2014 04:06:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5XHm-00074C-Le for emacs-devel@gnu.org; Tue, 21 Jan 2014 04:06:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5XHd-0006a9-61 for emacs-devel@gnu.org; Tue, 21 Jan 2014 04:06:18 -0500 Original-Received: from mx1.bahnhof.se ([213.80.101.11]:53682) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5XHc-0006Zt-S2 for emacs-devel@gnu.org; Tue, 21 Jan 2014 04:06:09 -0500 Original-Received: from localhost (mf.bahnhof.se [213.80.101.20]) by mx1-reinject (Postfix) with ESMTP id 81FE88ABDF8; Tue, 21 Jan 2014 10:06:06 +0100 (CET) X-Virus-Scanned: by amavisd-new using ClamAV at bahnhof.se (MF4) Original-Received: from mf4.bahnhof.se ([127.0.0.1]) by localhost (mf4.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRuI0c2Wut5m; Tue, 21 Jan 2014 10:06:03 +0100 (CET) Original-Received: from mta.verona.se (h-235-102.a149.priv.bahnhof.se [85.24.235.102]) by mf4.bahnhof.se (Postfix) with ESMTP id 60AF83D7849; Tue, 21 Jan 2014 10:06:02 +0100 (CET) Original-Received: from localhost (unknown [127.0.0.1]) by mta.verona.se (Postfix) with ESMTP id 3CAED4E77BE; Tue, 21 Jan 2014 09:05:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at verona.se Original-Received: from mta.verona.se ([127.0.0.1]) by localhost (exodia.verona.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3bOjoApxg5p; Tue, 21 Jan 2014 10:05:51 +0100 (CET) Original-Received: from exodia.verona.se (www.verona.se [192.168.200.15]) by mta.verona.se (Postfix) with ESMTP id 4D6964E77BA; Tue, 21 Jan 2014 10:05:51 +0100 (CET) In-Reply-To: <87lhy9zsab.fsf@mail.jurta.org> (Juri Linkov's message of "Tue, 21 Jan 2014 09:51:40 +0200") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Mac OS X 10.x X-Received-From: 213.80.101.11 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:168814 Archived-At: Juri Linkov writes: >>> Storing the command, too, is also nice, because then we can re-run the >>> command with the `g' command. >> >> Yes, I like that too. I actually want to move in that direction, >> defining a way for a major mode to advertise how to rebuild the >> "same" buffer. Then special-mode could set revert-buffer-function to >> a new function which would use this info, and bookmark.el could also use >> that info. > > And in desktop.el it would be nice as well to save/restore > non-persistent buffers like *Help*, *Occur*... > >>> However, re-running an external command will not, in general, give us >>> the same buffer we had before. Things change, and re-running (say) grep >>> half an hour later might very well give us a different buffer than what >>> we expected (because files have changed, etc). >> >> Indeed, that's a downside. In the case of eww, for example, I find it >> very important to be able to go back to a previous page's content >> without re-contacting the web-server. This would probably be true also >> in some other cases, such as *vc-diff*. > > When I forget to rename-uniquely *vc-diff* and it gets overwritten > by new content, I'm trying to do `undo' to restore it to the > previous state. If it's possible to combine the proposed feature > of using strings with undo information, it could help to navigate > the history of previous content of the buffer. > >>> Having a history that presents us with ever-changing output doesn't seem >>> optimal. >> >> I think sometimes we want one and sometimes we want the other. Not sure >> how to reconcile this without exposing this choice to the user in an >> annoying way. > > It seems there are three possible separate features > and any combination of them can be used at the same time: > > 1. Rename uniquely each buffer whose content is going to be overwritten, > e.g. creating buffers like *Help: car*, *Help: cdr*, ... > This is useful, but should not be the default. > > 2. Keep previous content in buffer-local strings (like eww does). > Useful when auto-renaming buffers will produce too many buffers. It seems to me that we could work on making it more convenient with many buffers. There is already a mechanism to hide buffers, by having an inital space in the name. Intuitively the overhead of many buffers is not much more than the overhead of string storage. At any rate, this is how I manage this problem locally at the moment. I just rename grep buffers I want to remember. > 3. Set a function to regenerate content (like *Help* currently does). > Useful for bookmarks, desktop. This is also useful. I suppose I just wanted to say that I agree with you, but perhaps the many buffers approach shouldnt necessarily be the least attractive option. -- Joakim Verona