Re: Async package.el

[Artur Malabarba]

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