Re: Async package.el

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

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

> The first example runs a server that will serve the current directory:
http://www.linuxjournal.com/content/tech-tip-really-simple-http-server-python
>
> We don't need much more than that, right?

I think that should be enough, thanks.

>> 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).
>
>
> Personally, I'm a little annoyed with the blinking. And the small
stuttering when the table is being regenerated.

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.

> And the fact that I can miss the message when the archives get refreshed
just by interacting with Emacs (maybe flooring C-n right after the buffer
is displayed), and then remain vaguely unsure the refresh has happened.

Also next on the list is a visual cue to indicate there's an ongoing
operation. Something like this:



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

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

>
>
>> 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".
>
>
> I guess that would work.
>
>
>> 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.
>
>
> And more dangerous, at least theoretically. Here's a made up scenario: I
select a package, the archive updates, it contains a new version of the
same package, which has unresolved dependencies (a situation which we mark
as "incompatible"). Whether we transfer the installation mark or not, the
user could install the package they wanted (at least if the archive server
still contains the file); now they can't. It might have even jumped away to
the bottom.

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

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