From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Giorgos Keramidas Newsgroups: gmane.emacs.help Subject: Re: an inconvenient difference in Emacs 22 Date: Sat, 22 Sep 2007 23:56:33 +0300 Organization: SunSITE.dk - Supporting Open source Message-ID: <874phmwha6.fsf@kobe.laptop> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1190497240 18919 80.91.229.12 (22 Sep 2007 21:40:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 22 Sep 2007 21:40:40 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Sep 22 23:40:33 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IZCiH-0007EH-Do for geh-help-gnu-emacs@m.gmane.org; Sat, 22 Sep 2007 23:40:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZCiE-0001iR-V4 for geh-help-gnu-emacs@m.gmane.org; Sat, 22 Sep 2007 17:40:31 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!goblin1!goblin2!goblin.stu.neva.ru!news.net.uni-c.dk!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (berkeley-unix) Cancel-Lock: sha1:CT1lBo6VLeuIkGk9AgSilcMhfcY= Original-Lines: 60 Original-NNTP-Posting-Host: 81.186.70.234 Original-X-Trace: news.sunsite.dk DXC=0k7cl0c; F3T0[?SRcYIYmQYSB=nbEKnk[9KI=c`M<`][L^MjWX7f^UIZ@YZYNiB:4CK7m7_aBA[bJ^Q_[[ Original-X-Complaints-To: staff@sunsite.dk Original-Xref: shelby.stanford.edu gnu.emacs.help:152238 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:47746 Archived-At: On 21 Sep 2007 22:21:54 -0400, Steve Newcomb wrote: > In the end, an even better approach, at least for our purposes, may be > global-auto-revert-mode. I am chagrined to discover that this mode > has been around for a while, and I just didn't know it. Until I read > your suggestions, I had never understood that, in the jargon of Emacs, > "revert-buffer", means "update the buffer". The name was probably chosen because it "reverts any in-memory modifications the buffer includes, and reloads its contents to what is stored on disk." It may seem a bit unintuitive, but now you know it's there and another cool feature of Emacs can make your every day life easier :-) > I'm curious about this usage of the word "revert". "Revert" normally > connotes some sort of retrograde motion. As far as I know, it never > connotes forward motion at all, much less forward motion undertaken to > catch up with someone else's forward motion. But, until I'm > corrected, that's how I'll understand "revert" in the context of > Emacs. "revert" is also used in the Source Code Management world. There is at least one particular use of "revert" which matches precisely the meaning of "revert" in Emacs lore. In the Perforce SCM, every file of a local workspace is checked-out as read-only[1]. Before making local changes, Perforce users are expected to run "p4 edit filename" or "p4 open filename", to notify the central repository server that they are going to make changes to the file. Once a file is "opened", it becomes a part of the active changelist and it no longer receives updates from the repository, even if another developer modifies it. It is something like "a local buffer for a historical copy of the file's contents". If the developer wants to throw away all local changes, and synchronize her copy with the latest version of the file in the repository, then the appropriate incantation is: p4 revert filename This does not necessarily "revert" the file contents to the version which had been historically checked out, but it "reverts the local file copy to the latest version of the file in the repository". When a Perforce user runs "p4 revert", the same sort of "forward movement" you describe with Emacs buffer contents happens if another developer has checked-in changes in the mean time :-) Notes ***** [1] There is an option to check out read-write copies, but it is generally frowned upon and it makes life somewhat harder down the road. But that's irrelevant here.