[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Async package.el

From: Artur Malabarba
Subject: Re: Async package.el
Date: Wed, 8 Apr 2015 00:26:59 +0100

Somehow I hadn't seen this message before.

On Apr 7, 2015 2:19 AM, "Dmitry Gutov" <address@hidden> wrote:
> I'd also prefer to revert to use the sentence case (non-caps).

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.
Maybe just the "Delete" word should be all-caps, and only if there are other operations in the same message. Or maybe "Delete" should just come first.

> I think ideally you'd run a small package archive server locally, launched with a tiny Python script.

I'd appreciate any help with that. The only server I know how to run nowadays is with Jekyll.

> Right, that should be optimal, but the requires changes are probably non-trivial.


> To take this further (and forgive the negativity), maybe we should back-pedal on adding the asynchronous interface to downloading package archives, too. While doing it in parallel is great, refreshing the table of packages right under the user's nose is bound to create problems. Here's one:
> M-x list-packages, press `i' in the displayed list, wait for the refresh to be done, see the `I' disappear.

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).

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".

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]