From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Async package.el Date: Wed, 08 Apr 2015 19:02:49 +0300 Message-ID: <55255129.4030002@yandex.ru> References: <55228FD2.3080501@yandex.ru> <552330A2.1090406@yandex.ru> <55249033.6050301@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1428509010 22273 80.91.229.3 (8 Apr 2015 16:03:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Apr 2015 16:03:30 +0000 (UTC) Cc: emacs-devel To: bruce.connor.am@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 08 18:03:25 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 1YfsRo-0006hn-2w for ged-emacs-devel@m.gmane.org; Wed, 08 Apr 2015 18:03:24 +0200 Original-Received: from localhost ([::1]:53727 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfsRn-0005om-DH for ged-emacs-devel@m.gmane.org; Wed, 08 Apr 2015 12:03:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfsRP-0005iB-Co for emacs-devel@gnu.org; Wed, 08 Apr 2015 12:03:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfsRI-0008M0-Sn for emacs-devel@gnu.org; Wed, 08 Apr 2015 12:02:59 -0400 Original-Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:37255) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfsRI-0008LT-N6 for emacs-devel@gnu.org; Wed, 08 Apr 2015 12:02:52 -0400 Original-Received: by wiaa2 with SMTP id a2so64574027wia.0 for ; Wed, 08 Apr 2015 09:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PYUwo3a1Q+ua9RHTi/qaKehLRsQTrLYejX6G4SZuXQ0=; b=d8nXtSdvUPvaZ5lwhubSi6C4RTbANxim3iOBvfH2KwZ9UBfPrLS2MwzeWCyS8HFk3Y rQQX/HWXygJLjbjWXI+OndUX9kzE4b3ZZXDo5CBPX6vj7WA3zkmzXSkaY4cHdDjMhxhE aTXoWIpfvhnumKv0VUGhxO9L/o1+zEYHri0R8ThADgulloyxjEoBDD4P22WLFreDOpqJ RJz6jW3zET1wZPBHfdC6RStxpQOPmwPKWQhMBXpM4XjyZ6jCBEYecpsky8PgY9asxdh9 bDajXCBIhPtNpceX2EzSuUp7I7dRquv0R40TJm5Ov5bcEwfDcMp7aSsGPssdljdMVme5 kvMA== X-Received: by 10.180.7.194 with SMTP id l2mr15736009wia.39.1428508972102; Wed, 08 Apr 2015 09:02:52 -0700 (PDT) Original-Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id gt4sm16256922wib.21.2015.04.08.09.02.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 09:02:50 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22b 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:185156 Archived-At: On 04/08/2015 12:43 PM, Artur Malabarba wrote: > Next in my list of TODOs is to change the behaviour when > package-menu-async is nil. Right now, it just reverts to the old > behaviour (sequential downloads + hang interface), but I plan to make it > do "parallel downloads + hang the interface", which might be more to > your liking. I think if you intend to keep the asynchronous interface, first we should try to make it work for most people. It's not that I absolutely hate it anyway. Maybe try the "merge individual items a la PCL-CVS" strategy, as suggested by Stefan. > Also next on the list is a visual cue to indicate there's an ongoing > operation. Something like this: Spinners are cute, but maybe we can start with a [waiting...] mode-line entry, a la vc-dir. > So there should be no doubt about when has the update finished (this > spinner will be local to the packages buffer, so it won't distract you > if you're trying to work). I'm not sure how many will find this "useful > information" and how many will think it "annoying distraction from hell". Thanks. I think it's useful, and it has precedent, mentioned above. > > Here's a more subtle scenario, by the way (but easier to fix): M-x > list-packages, then PageDown. Wait for the refresh -> see the current > line get scrolled to the middle of the window. ^ You haven't commented on this one. > >> One way to address this is to simply not regenerate the buffer if > >> anything has been marked. In this situation, the "refresh finished" > >> message can be accompanied by a "hit g to revert buffer" message. > > I guess that would work. Let's think about this: suppose the user has selected a few items with 'i', then she's going to press 'x'. - If she hasn't managed to hit it yet, are we comfortable with overtaking the interface just before that, with the "would you like to reload" question? If we do, we both interrupt the user's train of thought and risk confusing her with "press y on n" if she presses 'x' by inertia right after the new prompt. - If she's pressed 'x' already, will we be able to avoid interrupting the subsequent 'y or n' prompt? Then, when she presses 'y', will the "would you like to revert" prompt appear immediately? If she chooses to revert, could that lead to problems with installation, by introducing inconsistency in the package information? > If I understand the way archive servers work, they all just offer the > latest package version. So, in this scenario, trying to install the old > (compatible) version would lead to 404 error anyway. If that's the case, > then, arguably, removing the user's install mark would be the correct > choice (although an explanatory message might be in order). GNU ELPA does keep the previous versions, see the "old versions" list: http://elpa.gnu.org/packages/let-alist.html Even if other package archives don't, keeping older versions is a valid direction for improving package.el. We don't want to make it harder.