From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Occur stack Date: Tue, 21 Jan 2014 09:51:40 +0200 Organization: JURTA Message-ID: <87lhy9zsab.fsf@mail.jurta.org> References: <52D6D907.4030702@online.de> <52D8E8CB.5080600@online.de> <87eh45jk5p.fsf@building.gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390291274 23977 80.91.229.3 (21 Jan 2014 08:01:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jan 2014 08:01:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 21 09:01:22 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 1W5WGv-0001uU-KI for ged-emacs-devel@m.gmane.org; Tue, 21 Jan 2014 09:01:22 +0100 Original-Received: from localhost ([::1]:56096 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5WGv-0000gf-9b for ged-emacs-devel@m.gmane.org; Tue, 21 Jan 2014 03:01:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5WGm-0000cf-8l for emacs-devel@gnu.org; Tue, 21 Jan 2014 03:01:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5WGg-0002xj-7k for emacs-devel@gnu.org; Tue, 21 Jan 2014 03:01:12 -0500 Original-Received: from [69.163.184.122] (port=34980 helo=ps18281.dreamhostps.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5WGg-0002xY-2R for emacs-devel@gnu.org; Tue, 21 Jan 2014 03:01:06 -0500 Original-Received: from localhost.jurta.org (ps18281.dreamhostps.com [69.163.184.122]) by ps18281.dreamhostps.com (Postfix) with ESMTP id A34AB301D046F0; Tue, 21 Jan 2014 00:01:04 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Sat, 18 Jan 2014 21:45:32 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 69.163.184.122 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:168813 Archived-At: >> 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. 3. Set a function to regenerate content (like *Help* currently does). Useful for bookmarks, desktop.