The old code was messing up in case of `coalton-toplevel'.

It doesn't work the same way as before, since `ivy-read' is used to
select the value. However, `unread-command-events' don't seem to work
in batch mode.

…int ok

Print which variable will be set to what.

In Python 3.10, there's no collections.KeysView

Fixes abo-abo#611

Fixes abo-abo#599
Fixes abo-abo#606
Re abo-abo#537

Re abo-abo#537
Re abo-abo#606

Re abo-abo#599

Ensures that swiper and ivy only load on demand.

Fixes abo-abo#616

* lispy.el (lispy--action-jump): Remove `with-ivy-window', it's not needed.

Fixes abo-abo#616

… compliment

Re abo-abo#615

* le-clojure.el (lispy-cider-jack-in-dependencies): Default to nil.

Fixes abo-abo#615

Fixes abo-abo#614

* Decision
Given this context:
    #+begin_src python
    xs = ["1", "2", "3"]
    x = "2"
    #+end_src

~e~ on src_python{x in xs} should print "True"
~p~ on src_python{x in xs} should give the option to set =x= to become one of the values of =xs=.

* Rationale
src_python{x in xs} is a very common pattern in Python that has two meanings:
1. is the item in the collection
2. iterate over the collection

The split between the two meanings is 50/50, to say roughly. No one meaning prevails over
another.

The default in Python REPL is to choose meaning-1. Previously, lispy would give ~e~
meaning-2. In this way, both bases were covered. If meaning-1 was desired, copying the
code, switching to the REPL and pasting it directly would "work".

This is, however, inconvenient. So we introduce another binding ~p~ to mean "alternative
eval", just like we already have in Elisp and Clojure. And have ~e~ do the usual meaning-1
eval in this case, while ~p~ will do the meaning-2 eval.

…rror

… dict keys

This may happen when trying to load on a remote system that has nothing installed.

…ut completion

So that random Python output doesn't mess up our `read'.

Fixes abo-abo#641
Fixes abo-abo#642