From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: Patch to make VC annotate async Date: Mon, 25 Jun 2007 09:24:14 -0600 Message-ID: References: Reply-To: tromey@redhat.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1182788864 29076 80.91.229.12 (25 Jun 2007 16:27:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2007 16:27:44 +0000 (UTC) Cc: Emacs Hackers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 25 18:27:43 2007 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.50) id 1I2rPi-0004ol-OX for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 18:27:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2rPi-000289-4R for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 12:27:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I2rPV-00020d-SV for emacs-devel@gnu.org; Mon, 25 Jun 2007 12:27:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I2rPT-0001zX-73 for emacs-devel@gnu.org; Mon, 25 Jun 2007 12:27:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2rPS-0001zT-W7 for emacs-devel@gnu.org; Mon, 25 Jun 2007 12:27:27 -0400 Original-Received: from mx2.redhat.com ([66.187.237.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I2rPS-0000Ee-E5 for emacs-devel@gnu.org; Mon, 25 Jun 2007 12:27:26 -0400 Original-Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx2.redhat.com (8.13.1/8.13.1) with ESMTP id l5PFvl2g009731; Mon, 25 Jun 2007 12:27:19 -0400 Original-Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l5PFhcf9031570; Mon, 25 Jun 2007 11:43:38 -0400 Original-Received: from opsy.redhat.com (ton.toronto.redhat.com [172.16.14.15]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l5PFha4G027997; Mon, 25 Jun 2007 11:43:37 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 9CF9D888032; Mon, 25 Jun 2007 09:24:14 -0600 (MDT) X-Attribution: Tom In-Reply-To: (Stefan Monnier's message of "Sun\, 24 Jun 2007 21\:34\:27 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.990 (gnu/linux) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:73834 Archived-At: >>>>> "Stefan" == Stefan Monnier writes: >> The slowdown with svn seems to come while computing the text to send; once >> sent it seems to arrive quickly enough that I don't notice the contents >> not being fontified. Stefan> In the case of CVS, the annotated text is sent directly from Stefan> the server, so the rhythm at which it arrives depends on the Stefan> speed of your connection. Maybe SVN computes the annotated Stefan> text locally, in which case the network connection would only Stefan> be involved before the result starts showing up. Or maybe my network connection is faster. I didn't look too deeply into this. Stefan> But then I wonder: why did you bother to introduce this async Stefan> patch (since you seem to find the "context switch" to Stefan> something else to be a problem rather than a feature)? For me the question here is when the buffer should be displayed. It could be displayed immediately, or it could be displayed after the contents are all available. I tried both. Delaying the display of the buffer felt a bit unfriendly because the creation of a new window will rearrange the display enough that I lose track of point. On the other hand, immediately displaying the buffer gives me time to adjust and continue working. I hope this explains things a bit better; this area is somewhat subjective and I notice that at least one other package has gone the maximally configurable approach here -- see Man-notify-method. Stefan> Oh, I see, I had completely forgotten about it, but yes I have it Stefan> written as: Stefan> (with-current-buffer buffer Stefan> ;; FIXME: it'd be even better to do it in the process-filter. This suggests that you preferred the approach I took ;-) But, I don't really care. I can rewrite it to use vc-exec-after -- if that is what you want, let me know, and I will send a new patch. Tom