From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: vc-update for bzr etc. Date: Tue, 23 Nov 2010 17:34:31 -0500 Message-ID: References: <87y68m7kdh.fsf@stupidchicken.com> <87lj4mk2e5.fsf@stupidchicken.com> <87mxp2bd12.fsf@stupidchicken.com> <87tyjauga0.fsf@stupidchicken.com> <87eiacg6lj.fsf@stupidchicken.com> <87d3pvalem.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1290551694 25192 80.91.229.12 (23 Nov 2010 22:34:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 23 Nov 2010 22:34:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 23 23:34:50 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PL1Rh-0001RQ-Ug for ged-emacs-devel@m.gmane.org; Tue, 23 Nov 2010 23:34:42 +0100 Original-Received: from localhost ([127.0.0.1]:51196 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PL1Rh-0004vU-Gq for ged-emacs-devel@m.gmane.org; Tue, 23 Nov 2010 17:34:41 -0500 Original-Received: from [140.186.70.92] (port=54505 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PL1Rb-0004uY-4R for emacs-devel@gnu.org; Tue, 23 Nov 2010 17:34:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PL1Ra-0000uN-4s for emacs-devel@gnu.org; Tue, 23 Nov 2010 17:34:35 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:42091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PL1Ra-0000uJ-2B for emacs-devel@gnu.org; Tue, 23 Nov 2010 17:34:34 -0500 Original-Received: from dann by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1PL1RY-0005ia-23; Tue, 23 Nov 2010 17:34:32 -0500 In-Reply-To: <87d3pvalem.fsf@stupidchicken.com> (Chong Yidong's message of "Tue\, 23 Nov 2010 14\:29\:37 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133094 Archived-At: Chong Yidong writes: > Dan Nicolaescu writes: > >> I have an implementation of `pull' that also takes a `revision' argument. >> And in the *vc-incoming* buffer there's a binding for vc-pull to pull >> up to the revision at point (use pull --revision=ARG). > > Good. BTW, I have no plans to merge that. > >>> Also, do I need to do anything special to update VC-dir buffers after >>> merging or pulling? >> >> Not only VC-dir buffers, but all buffers containing files in the >> target directory. See for example the vc-resynch-buffer in the >> vc-retrieve-tag (which could use a better name). > > OK, I've got some code working that makes vc-bzr-merge/update call or > refresh VC-dir after finishing, e.g. it shows "updated" files after a > bzr update. But the interface feels flimsy, somehow. It seems that you are putting too much code in the vc-bzr, not in vc itself. Better pass the buffer to the command, instead of creating it locally in each VC backend. > > The VC-dir buffer displays no indication while the merge/pull is > running. Afterwards, there is no sign that the operation has completed, > other than an echo area message (easily overwritten by other Emacs > commands) and some changes in file status (easily overlooked). > > For example, if you do an update operation that completes without doing > anything, it's easy to miss when the update finishes. In contrast, when > the VCS messages are put into a compilation-like buffer, it's always > clear what has taken place. > > So it seems like there needs to be some kind of status message display > in the VC-dir buffer, showing (at least) the most recent VCS operation > and its status. WDYT? In the buffer? The way pcl-cvs does it is a bad idea, I am completely against it. Putting something in the modeline, like the rest of the vc asynchronous commands do would be better.