Re: Async package.el

[Artur Malabarba <bruce.connor.am@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

Somehow I hadn't seen this message before.

On Apr 7, 2015 2:19 AM, "Dmitry Gutov" <dgutov@yandex.ru> 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.

Indeed.

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

[-- Attachment #2: Type: text/html, Size: 2416 bytes --]