From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Benjamin Rutt Newsgroups: gmane.emacs.help Subject: Re: C-x v g going further back in time? Date: Mon, 26 Jan 2004 10:03:30 -0500 Organization: The Ohio State University Dept. of Computer and Info. Science Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1075130318 19930 80.91.224.253 (26 Jan 2004 15:18:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 26 Jan 2004 15:18:38 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Jan 26 16:18:32 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Al8VT-0000Qu-00 for ; Mon, 26 Jan 2004 16:18:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Al8T9-00007x-4K for geh-help-gnu-emacs@m.gmane.org; Mon, 26 Jan 2004 10:16:07 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!news-hog.berkeley.edu!ucberkeley!news.cis.ohio-state.edu!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 37 Original-NNTP-Posting-Host: mu.cis.ohio-state.edu Mail-Copies-To: nobody User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (usg-unix-v) Cancel-Lock: sha1:I4xq0g476tKAhEn1Qv+JJgMg4vk= Original-Xref: shelby.stanford.edu gnu.emacs.help:120424 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:16368 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:16368 Stefan Monnier writes: >> 1) the *vc* buffer is used both for 'C-x v l' and also when you do >> 'C-x v v' to commit a file, so it might contain either info that > > It can also be used for another file. I think we just need to add > a variable that stores the "it's a log" info, along the one that stores the > file's name. I guess a buffer-local variable will do in the *vc* buffer; this new variable would have a default value of nil, and will only be set to something meaningful when the log message history is requested. >> 2) cache coherency problem. What if the log info is updated b/c of >> new commits? Do you always want the outdated log info? > > I wouldn't worry too much about it. If the commits are done via VC, > they'll overwrite the *vc* buffer so it's safe. And even if it > somehow does not happen, it's rather unlikely that the user will be > bothered by the lack of some brand new commits: when using > vc-annotate you're typically looking at past changes. And you can > always add a `revert-buffer-function' such that the user can refresh > explicitly the log info. I was actually thinking of putting the cache logic into `vc-print-log', which can be invoked independently of the 'C-x v g', 'C-x o', 'L' path. But I think if they invoke 'C-x v l' directly, though, they should get the latest info always, otherwise they might wonder if their recent commit actually succeeded, since the log wouldn't show it if it was cached. Hmm. The logic for setting up the "*vc*" buffer is inside `vc-print-log', so it seems wrong to put the cache logic that refers to that buffer outside of that method. Maybe `vc-print-log' should take an argument that names the buffer, and has a reasonable default of "*vc*" when called interactively? What do you think? -- Benjamin