Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lispy.el (lispy-unbind-variable): Call iedit-update-occurrences #607

Open
wants to merge 223 commits into
base: master
Choose a base branch
from

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 30 commits December 5, 2024 09:04
When using the code, we relied on `top_level' for setting global bindings.
This no longer worked when using `pytest' for testing.
I like this change because it also is a step towards reflecting how Python uses frames for eval,
instead of just shadowing everything in top level.
* 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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug? lispy-unbind-variable does not replace the unbound variable with its value as described in docs
10 participants