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 05:19:31 +0300 Message-ID: <55249033.6050301@yandex.ru> References: <55228FD2.3080501@yandex.ru> <552330A2.1090406@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 1428459602 10673 80.91.229.3 (8 Apr 2015 02:20:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Apr 2015 02:20:02 +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 04:19: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 1Yffaq-0001re-Vx for ged-emacs-devel@m.gmane.org; Wed, 08 Apr 2015 04:19:53 +0200 Original-Received: from localhost ([::1]:50113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yffaq-0006lp-25 for ged-emacs-devel@m.gmane.org; Tue, 07 Apr 2015 22:19:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yffac-0006lX-9n for emacs-devel@gnu.org; Tue, 07 Apr 2015 22:19:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YffaZ-0000q3-0s for emacs-devel@gnu.org; Tue, 07 Apr 2015 22:19:38 -0400 Original-Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:35093) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YffaY-0000py-PH for emacs-devel@gnu.org; Tue, 07 Apr 2015 22:19:34 -0400 Original-Received: by widdi4 with SMTP id di4so38252892wid.0 for ; Tue, 07 Apr 2015 19:19:34 -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=k7oq38Hx4b0465bdYbGZE34zmMM2o8Z5fleV0DqdIzQ=; b=svYAbqZElMAxFIe+Fvm4crz0yb5p0xP+o19DjZqbbpsH4BuXJcz1QszbjR3KW62AE8 2TmSjZX60jmmis8+3cPPYtwdq5axv8nmTtwviDryCgAoJQxlOIj7Ohq6i1nN0Tin2SNh Y0Yr9oSxierfpqEEWDNIVOMLYL6B2VGEMd04oOoi5khfCR2mMe51OLeq3Im3eCyLxwj8 8Asaws5ultheH1+EX6IYEoBwmz87M7mvovuam87zfwFUBvb0sQZm331oZC2FQxBKczkD +UIiJWYMHLLP1hTu2gCK6iC2nM4RYtlGAtCqs043XLzNscvvuELhFkXDBzsTWPB5cZ4I tKuA== X-Received: by 10.181.8.99 with SMTP id dj3mr10001555wid.83.1428459574165; Tue, 07 Apr 2015 19:19:34 -0700 (PDT) Original-Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id m4sm13417327wjb.25.2015.04.07.19.19.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 19:19:33 -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::22e 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:185126 Archived-At: On 04/08/2015 02:26 AM, Artur Malabarba wrote: > Somehow I hadn't seen this message before. Ok. I figured you were just taking your time composing the reply. > I changed it to caps because, if there's a long list of packages to be > installed, it's a little easy to overlook the fact that you're also > being asked about a deletion. Well, I don't know. Usually it's just the one word (UPGRADE), and by itself it looks grating. > Maybe just the "Delete" word should be all-caps, and only if there are > other operations in the same message. Use bold face, but keep it sentence-case? > Or maybe "Delete" should just come first. Yeah, this would probably be the best approach. > I'd appreciate any help with that. The only server I know how to run > nowadays is with Jekyll. The first example runs a server that will serve the current directory: http://www.linuxjournal.com/content/tech-tip-really-simple-http-server-python We don't need much more than that, right? > I agree this needs addressing, but it will take a lot more than that for > me to backpedal on the archive refreshing part. I'm actually very happy > with the resulting UX. (Unlike the package-installation part, which I'm > still not thrilled about). Personally, I'm a little annoyed with the blinking. And the small stuttering when the table is being regenerated. And the fact that I can miss the message when the archives get refreshed just by interacting with Emacs (maybe flooring C-n right after the buffer is displayed), and then remain vaguely unsure the refresh has happened. Yeah, most of this could just be the aversion to change. :) 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. > 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. > This would be easily scalable. Whenever a new feature is added which > involves some semi persistent information, we'd just extend the > definition of "anything has been marked". I guess that would work. > A second, more sophisticated way would be to not revert the buffer at > all. Instead, we carefully update the information currently displayed in > the buffer. Though this is more troublesome, of course. And more dangerous, at least theoretically. Here's a made up scenario: I select a package, the archive updates, it contains a new version of the same package, which has unresolved dependencies (a situation which we mark as "incompatible"). Whether we transfer the installation mark or not, the user could install the package they wanted (at least if the archive server still contains the file); now they can't. It might have even jumped away to the bottom.