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: "Staying in the same place" Date: Mon, 04 Apr 2016 08:51:47 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1459774342 12835 80.91.229.3 (4 Apr 2016 12:52:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Apr 2016 12:52:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 04 14:52:15 2016 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 1an3zL-0007xA-As for ged-emacs-devel@m.gmane.org; Mon, 04 Apr 2016 14:52:15 +0200 Original-Received: from localhost ([::1]:58439 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1an3zK-0007Xi-Hj for ged-emacs-devel@m.gmane.org; Mon, 04 Apr 2016 08:52:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1an3z6-0007XS-7R for emacs-devel@gnu.org; Mon, 04 Apr 2016 08:52:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1an3z2-0005Ru-73 for emacs-devel@gnu.org; Mon, 04 Apr 2016 08:52:00 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:59036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1an3z2-0005Rq-03 for emacs-devel@gnu.org; Mon, 04 Apr 2016 08:51:56 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1an3yz-0007p1-MG for emacs-devel@gnu.org; Mon, 04 Apr 2016 14:51:53 +0200 Original-Received: from 69-165-138-79.dsl.teksavvy.com ([69.165.138.79]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2016 14:51:53 +0200 Original-Received: from monnier by 69-165-138-79.dsl.teksavvy.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2016 14:51:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 41 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 69-165-138-79.dsl.teksavvy.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:pkrwxJt6BXGMp1bqnSXqFulfiwY= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:202681 Archived-At: > There's a lot of modes in Emacs that don't reflect a physical file, but > has only generated content (for some values of "generated"). Many of > these implement a version of "revert", usually bound to the `g' key, > which basically do an `erase-buffer' and then generate the buffer anew. I think it'd good to think of such solutions in the context of bookmarks as well. IOW, I think ideally, there should be a special-mode-revert-buffer function (which special-mode sets as the default value of revert-buffer-function), which basically just does a "get bookmark data, then go back to that bookmark". I don't think it can be done with the current bookmark data, tho. IIRC there were 2 main reasons: - You need to be able to distinguish the case "go back to bookmark in a new buffer" and "go back to bookmark in the current buffer". - You probably want to distinguish between the case where you want to revert/refresh, and the case where it's OK to just jump to some spot in some existing buffer. Last time I looked at it, I also figured that it'd be nice if the help-xref-* could use the same infrastructure. > And then you have to implement some way of "staying in the same place". Bookmarks do that part acceptably, I think. > (The reason I'm thinking about this is that I was thinking about what > would be necessary to make `g' in compilation buffers remain in "the > same place". Which is useful when you're trying to weed out compilation > warnings.) Oohh.. that's yet another step up in complexity since in that case you can't "go back" right away, you first have to wait for the process to send enough data. But yes, that would be great (I'd particularly appreciate it in *vc-diff*). Stefan