Re: Async package.el

[Dmitry Gutov]

On 04/08/2015 12:43 PM, Artur Malabarba wrote:

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

Maybe try the "merge individual items a la PCL-CVS" strategy, as 
suggested by Stefan.

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

> So there should be no doubt about when has the update finished (this
> spinner will be local to the packages buffer, so it won't distract you
> if you're trying to work). I'm not sure how many will find this "useful
> information" and how many will think it "annoying distraction from hell".

Thanks. I think it's useful, and it has precedent, mentioned above.

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

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

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

If she chooses to revert, could that lead to problems with installation, 
by introducing inconsistency in the package information?

> If I understand the way archive servers work, they all just offer the
> latest package version. So, in this scenario, trying to install the old
> (compatible) version would lead to 404 error anyway. If that's the case,
> then, arguably, removing the user's install mark would be the correct
> choice (although an explanatory message might be in order).

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.