Add option to select packages for update

[dalanicolai]

Due to a question by @pataquets just now on gitter, I have added an option to select packages for installation.
I've tested it, and it seems to work perfectly fine, incl. the rollback(s). I prefer the read-answer solution, but of course
we could make it a completing-read also.

The diff looks a little strange b.t.w., because it shows many 'removed/red' hunks, that I did not remove at all (so those parts appear in 'green' further below).

BELOW IS THE COMMIT MESSAGE

This commit changes the yes-or-no-p to a read-answer with three options y, s and
n (for yes, some and no. This of course could be a, s, c for 'all',
'some/select' and 'cancel', but I decided to keep yes no as users are already
familiar with the y and n).

Finally the user can select packages by answer for each package in the list a
yes-or-no-p (pressing y or n, if you upgrade regularly the list usually is not
too long. It is anyway better than having only the options all or none).

The nonc construction is just a non cl alternative to cl-remove-if (I've added
the comment with the explanation).

[lebensterben]

selection based on y/n questions will be very verbose.

It's possible to write the packages to a new buffer, for example,

# 'd': delete a package from update list
# 'u': undo
# 'C-c C-c': confirm and update
# 'C-c C-k': abort
foo
bar
baz

Assign an empty keymap to the buffer with only the above-mentioned key bindings, arrow keys/hjkl keys for navigation, and SPC-* prefix commands.

Anything remained in the buffer is updated.

What do you think?

[dalanicolai]

Yeah, I thought about that, but it does not have enough priority for me to spend my time implementing it for the following reasons:

1. I've added this due to a question on gitter, but personally I always update all packages (if something breaks, I will help to fix it).
2. I update packages regularly, so generally, there are less than 10 packages to update.

Of course, if users prefer other ways of doing things, then they are welcome to contribute. As for sure, I do agree that your proposed solution is nicer. My solution is just a quick 'better than nothing'...

[pataquets]

Awesome! Thank you very much @dalanicolai.
I've fetched your PR branch and I'm using it. It works great (tested only for some). I'll be updating more packages in the following days and use yes at some point. Will report back if anything happens.

As UX feedback, at first I thought that (y, s, n) was not too intuitive for s unless familiar with the PR and I was ready to send a PR to add it. But when reading the code I've seen some help text and realized that there is the ? option key. 🤦
Also, I think @lebensterben's solution is less friendly for unexperienced users, IMHO. Individual questions, although more verbose, are far more intuitive.

I've tried to figure out how to pop up a Helm list with updated packages to be used as package chooser, but as of now it's still outside my abilities 😞. But it's more an attempt to add my 2c than a necessity. As it is now it works beautifully for me.

So, my only worry is if this is newbie-proof enough, since s in (y, s, n, ?) might not be obvious, as also CTRL+g is not when answering individual package (y/n) questions. Other than that, it works great.

[dalanicolai]

@pataquets Thanks for the feedback!

Well in the end I guess (Spac)emacs users have to get familiar with read-answer style question and its ?, so it is probably okay that users somehow find this out.

I do think that @lebensterben his solution will be as intuitive because the buffer will/should also contain an explanation, but, although it is not too much work, it is still too many minutes (for me) for the relative little gain.

Creating a solution for Helm, should be quite easy I guess (I think you can just use completing-read and 'marking in helm'). But the problem is that users use different completion backends, and support for all would probably (if working with completing-read) require separate implementations for each. Personally I was using Ivy because I found it slightly more straightforward to hack on it. And now I am using the new compleseus layer. Although that layer is still very new, I guess in the end it will become the most popular completion backend because it seems to provide a most clean and general implementation (simplest, minimally intrusive, and maximally compatible with Emacs), while 'effectively, there's a very strong and active "team" behind it/the packages of that layer.

[lebensterben]

@pataquets

If you believe (y s n ?) isn't intuitive enough:

SPC a k open paradox menu.
Click 'Paradox Menu' on modeline and select filter by upgrades.
Then you can upgrade whatever you want.

[dalanicolai]

Hi @dalanicolai . I have additional feedback on the PR.

I've been experiencing weird issues with Spacemacs automatic package install/removal. I've tried magit-org-todos via dotspacemacs-additional-packages using the github fetcher. It installed it OK, but I've decided to uninstall it. I've been fighting for the last two days with Spacemacs not removing it and, furthermore, when I manually deleted files and all references to package I've could grep, Spacemacs kept installing the package. No way to get rid of it, I've tried by all means.

Finally, when trying to follow the installation messages in the code, I've wandered if it could be due to the new code, which I was testing. Checked out develop branch, did SPC f e R and... tada! package went away as expected.

I've double checked by, using the same .spacemacs file, checking out develop and this PR branches back and forth, launching Spacemacs and exiting immediately. On develop branch, everything goes as expected, whereas the add-option-... branch behaves weirdly. :(

Adding a layer, temporarily makes Spacemacs to remove the package, but on next start, it keeps popping up.

I've performed three package updates using the (s)ome option with no problem. so far. However, it looks like to me that Spacemacs is using some old version of the installed packages or something alike, but my knowledge is very limited and I can't troubleshoot any further.

Emacs v.27.1 from kelleyk's PPA, Ubuntu Bionic. Spacemacs develop branch, fetched up-to-date.

@pataquets Did you solve this issue? I don't know the exact workings of how Spacemacs/Quelpa manages packages. I don't really expect this 'fix' for selecting updates should influence the behavior, but I am not sure. Maybe next time, you can try using SPC s f to search within the .emacs.d/.cache directory (even better if you could google how to include hidden folders in a helm/ripgrep search). But I am just guessing/suggesting, because otherwise I have no clue...

[dalanicolai]

@pataquets

If you believe (y s n ?) isn't intuitive enough:

SPC a k open paradox menu. Click 'Paradox Menu' on modeline and select filter by upgrades. Then you can upgrade whatever you want.

Nice! I did not know this feature. Just wondering if this is 'compatible' with Spacemacs its rollback feature. But anyway a nice menu...

[BenedictHW]

Just from my past experience, it's not compatible. @pataquets, there is also dotspacemacs-frozen-packages and dotspacemacs-excluded-packages if you want to hold a few packages back. On the flip side of upgrading cherry picked packages, you have @lebensterben's SPC a k solution. Either way, keep your /elpa/ directory under source control, at least until spacelpa hits master.

[smile13241324]

Looks good

[pataquets]

@dalanicolai For the record, my problem turned out to be something in my configuration getting in the way. The feature works nicely, thank you! (Sorry for getting back so late. I had an injury back then that kept me AFK).
Thanks again everyone.