Re: Async package.el

[Dmitry Gutov]

On 04/08/2015 02:26 AM, Artur Malabarba wrote:
> Somehow I hadn't seen this message before.

Ok. I figured you were just taking your time composing the reply.

> I changed it to caps because, if there's a long list of packages to be
> installed, it's a little easy to overlook the fact that you're also
> being asked about a deletion.

Well, I don't know. Usually it's just the one word (UPGRADE), and by 
itself it looks grating.

> Maybe just the "Delete" word should be all-caps, and only if there are
> other operations in the same message.

Use bold face, but keep it sentence-case?

> Or maybe "Delete" should just come first.

Yeah, this would probably be the best approach.

> I'd appreciate any help with that. The only server I know how to run
> nowadays is with Jekyll.

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 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. 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. Yeah, most of this 
could just be the aversion to change. :)

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.