Skip to content

Conversation

@papercatlol
Copy link

Fixes #576 on Emacs 27.2

papercatlol and others added 30 commits September 20, 2021 19:59
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.
Print which variable will be set to what.
In Python 3.10, there's no collections.KeysView
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
* le-clojure.el (lispy-cider-jack-in-dependencies): Default to nil. Fixes abo-abo#615
abo-abo and others added 29 commits December 5, 2024 09:04
* 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.
This may happen when trying to load on a remote system that has nothing installed.
So that random Python output doesn't mess up our `read'.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

10 participants