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