[Top][All Lists]

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

Re: Async package.el

From: Dmitry Gutov
Subject: Re: Async package.el
Date: Wed, 08 Apr 2015 19:02:49 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

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.

reply via email to

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