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: Async package.el Date: Wed, 08 Apr 2015 09:32:28 -0400 Message-ID: References: <55228FD2.3080501@yandex.ru> <552330A2.1090406@yandex.ru> <55248915.5070707@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1428500219 27654 80.91.229.3 (8 Apr 2015 13:36:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Apr 2015 13:36:59 +0000 (UTC) Cc: bruce.connor.am@gmail.com, emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 08 15:36:53 2015 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 1Yfq9y-00082O-Li for ged-emacs-devel@m.gmane.org; Wed, 08 Apr 2015 15:36:50 +0200 Original-Received: from localhost ([::1]:52817 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yfq9x-0005YH-QB for ged-emacs-devel@m.gmane.org; Wed, 08 Apr 2015 09:36:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yfq9i-0005Y1-8i for emacs-devel@gnu.org; Wed, 08 Apr 2015 09:36:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yfq9e-0007Es-8s for emacs-devel@gnu.org; Wed, 08 Apr 2015 09:36:34 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:16489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yfq9e-0007Em-5G for emacs-devel@gnu.org; Wed, 08 Apr 2015 09:36:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRBbthL/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCwsOJhIUGA0kiBOiEYwbBkMMA4M+A4NwBKg7 X-IPAS-Result: AgUFAGvvdVRBbthL/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCwsOJhIUGA0kiBOiEYwbBkMMA4M+A4NwBKg7 X-IronPort-AV: E=Sophos;i="5.01,1,1400040000"; d="scan'208";a="115702604" Original-Received: from 65-110-216-75.cpe.pppoe.ca (HELO pastel.home) ([65.110.216.75]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2015 09:32:28 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 9378B1392; Wed, 8 Apr 2015 09:32:28 -0400 (EDT) In-Reply-To: <55248915.5070707@yandex.ru> (Dmitry Gutov's message of "Wed, 08 Apr 2015 04:49:09 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:185148 Archived-At: > I haven't used PCL-CVS, but VC-Dir is a good counter-example: while it's > refreshed asynchronously, we don't really expect the user to do much while > that happens, other than maybe look at the output. It's just nicer to > have a responsive Emacs during this operation (which could be long in > certain cases). I think the issue is that currently, when the async download ends, we just completely rebuild the package-list, losing all previous info. This needs to be fixed. In PCL-CVS and in VC-Dir, when the async operation ends, we merge the result with the current buffer's content. So the user can mark/unmark elements which the async operation is in process and these things aren't lost afterwards (and neither is the position of point). > And when vc-dir buffer is initially displayed, we don't have any "stale" > data about the repository. In PCL-CVS we did. >> acceptable to add such a (mis)feature, but it should very clearly be OFF >> by default, since we don't want Emacs to "call home" in such a way >> by default. > Fair enough. I'm also more partial to the option 1 (only refresh > once a day), because it's more predictable, but the above would be closer to > how other systems and applications look for updates (in the background, > without bothering the user), so it should be something to consider. I'm perfectly OK with changing the "auto-update" so that it's not done at every call to list-packages (e.g. once a day is perfectly fine, indeed. I'd even agree with "never" and just let the user request an update manually). What I object to, is to do it even before list-packages is invoked. Stefan