From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: Async package.el Date: Wed, 8 Apr 2015 19:39:32 +0100 Message-ID: References: <55228FD2.3080501@yandex.ru> <552330A2.1090406@yandex.ru> <55249033.6050301@yandex.ru> <55255129.4030002@yandex.ru> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1428518395 22964 80.91.229.3 (8 Apr 2015 18:39:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Apr 2015 18:39:55 +0000 (UTC) Cc: emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 08 20:39:54 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 1YfutF-0000L1-2j for ged-emacs-devel@m.gmane.org; Wed, 08 Apr 2015 20:39:53 +0200 Original-Received: from localhost ([::1]:54346 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfutE-0002C0-AI for ged-emacs-devel@m.gmane.org; Wed, 08 Apr 2015 14:39:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yfusy-0002Be-Em for emacs-devel@gnu.org; Wed, 08 Apr 2015 14:39:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yfusx-0004dz-0o for emacs-devel@gnu.org; Wed, 08 Apr 2015 14:39:36 -0400 Original-Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:33536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yfusw-0004dr-FM for emacs-devel@gnu.org; Wed, 08 Apr 2015 14:39:34 -0400 Original-Received: by layy10 with SMTP id y10so72801073lay.0 for ; Wed, 08 Apr 2015 11:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ETvcJoKx2V08qpavj93S7J00OJ0C3vvikKSs5l/XERM=; b=okiN86rRgOd4zNcQ2+4iBP9XEu9Hzwzc55TFhm+ns6R9j8P0oVfqQZIxCsaLWpYc+J u6IlVEVUBM5ALBB34CqhQHu66SZECIPA11nJfreG/snTNtutyFdlEYHsxPox2mUn4bkQ tT2eLoMa+0CO17j2sYk3QxF9/6JmFs0xablKORwH+tNtIHSMcrgsbWIsTT1LY04ZY+07 50hC3vO+vsGp+Hni2QYWydyDlqs2u3lvyX/9KXA1kiJaksDP/CmAULe1Pv7IZIZBaTOW 3dMEk5HsANzQlI5hW3g7MJLOxAhQvVQ8XP37/dnOFtk9ZLSLsaKr04B4scSZVLsEZdij YnJQ== X-Received: by 10.152.43.110 with SMTP id v14mr860135lal.4.1428518372546; Wed, 08 Apr 2015 11:39:32 -0700 (PDT) Original-Received: by 10.25.150.131 with HTTP; Wed, 8 Apr 2015 11:39:32 -0700 (PDT) In-Reply-To: <55255129.4030002@yandex.ru> X-Google-Sender-Auth: 44t0E1TZ8Y_1MW201p2bpaEd6yo X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::235 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:185170 Archived-At: >> 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. It's also almost trivial to just hang the interface while a variable is non-nil. So it's no sacrifice to implement it. > Maybe try the "merge individual items a la PCL-CVS" strategy, as suggested > by Stefan. Yes, I do prefer this strategy too. For now I'm letting it bounce around in my head and mature a bit while I focus on some work stuff, but, as long as it doesn't turn out to be a monumental effort, I'll end up writing it at some point (unless someone else beats me to it). >> 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. Done. We can discuss if we want to improve it. >> > 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. Sorry. I figured this will get automatically fixed by any of the options already being discussed. For instance, if we do the "merge individual items", then nothing in the algorithm would recenter the window and this inconvenience should disapear. AFAICT, the only case where scrolling can happen in this scenario is if N new packages are added to the top while the cursor was less than N lines from the bottom of the window, and we should be able to avoid a complete recentering by let-binding `scroll-step' to a small value. (but I may be going too deep into the technicalities of something that's not even impemented). >> >> 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. The suggestion was not to use a question prompt, but to simply message "Package refresh done, type g to revert buffer" instead of the ususal "Package refresh done". > - 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? I thought we could use `(minibuffer-window-active-p (selected-window))' to check whether the minibuffer is active before sending the message. Unfortunately, although this works with `read-string' it doesn't work with `read-key' (which is what `y-or-n-p' uses). > If she chooses to revert, could that lead to problems with installation, by > introducing inconsistency in the package information? No. If she reverts, any "i" marks will be forgotten. This is a flaw of this approach, but one fortunate consequence is that there won't be any such inconsistency problems. > 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. Well, we're not really making it harder. This behaviour has always been the case. As soon as you `list-packages', old-compatible packages get forgotten in exchange for new-incompatible ones. The only difference is that now the user has a brief chance to see the old package before it is brutally taken beyond her reach. I think I can fix this if we want, but I don't think it's a flaw of the async interface.