From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Occur stack Date: Sat, 18 Jan 2014 21:45:32 -0500 Message-ID: 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 1390099545 9268 80.91.229.3 (19 Jan 2014 02:45:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 02:45:45 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 19 03:45:51 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 1W4iOU-00061E-QH for ged-emacs-devel@m.gmane.org; Sun, 19 Jan 2014 03:45:50 +0100 Original-Received: from localhost ([::1]:44939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4iOU-0008Cy-6Q for ged-emacs-devel@m.gmane.org; Sat, 18 Jan 2014 21:45:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54773) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4iOK-0008A1-IL for emacs-devel@gnu.org; Sat, 18 Jan 2014 21:45:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W4iOD-00031C-7q for emacs-devel@gnu.org; Sat, 18 Jan 2014 21:45:40 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:57786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4iOD-000316-10 for emacs-devel@gnu.org; Sat, 18 Jan 2014 21:45:33 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFMCplR/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBsEtjWGDKQOIYZwZgV6DFQ X-IPAS-Result: Av4EABK/CFFMCplR/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBsEtjWGDKQOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="45288102" Original-Received: from 76-10-153-81.dsl.teksavvy.com (HELO pastel.home) ([76.10.153.81]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Jan 2014 21:45:32 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 4D569603BA; Sat, 18 Jan 2014 21:45:32 -0500 (EST) In-Reply-To: <87eh45jk5p.fsf@building.gnus.org> (Lars Ingebrigtsen's message of "Sat, 18 Jan 2014 09:04:50 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.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:168714 Archived-At: >> Here's an other experimental code which does it the other way: >> it does not store buffer contents, it reruns the command >> instead. > 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. > 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*. Hmm... > 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. Stefan