lispy: New layer that puts lispy-mode toggle on M-m k #4596
Conversation
|
Why only for emacs style users ? :-) Since it is a layer, I guess you can make it exclude evil-lisp-state and remove the condition on the editing style, so anybody can try lispy. We may have some key binding tweaks in vim style, like for helm and ivy but we'll find out by using it. Excellent and so simple, I love that 💜 |
|
This is awesome if it's landing in spacemacs! I'm using this with hybrid style and feels amazing when writing lisp.
|
There's no need to remove evil-lisp-state as this effectively removes all of the evil-lisp-state entry points.
I think I ran into that already, but I didn't understand what was happening. Has it been reported?
Ok I'll fix that.
I can do that too. |
|
@justbur I didn't report the issue. Based on this comment I installed hydra and got it working. Which tells us we might need hydra as a direct dependency of lispy in layer packages and needs to be installed prior to lispy initialization. |
|
@nixmaniack That should be reported. hydra is not currently listed as a dependency of lispy in melpa |
|
@syl20bnr Check it now. I think this should work fine for all editing styles now |
|
@justbur I created issue abo-abo/lispy#180 but looking at discussion over here abo-abo/lispy#74 it seems it's unlikely. If that isn't resolved, you'll need to add it to layers packages. Also, is it alright to make lispy available in hybrid state everywhere? I had an issue with org mode previously(abo-abo/lispy#141, fixed as of now). So it might make sense to enable it in lisp related modes to avoid such issues. |
Good point. I intended to make it only available in the buffer you toggled it in, but these hooks don't do that. |
|
@nixmaniack It's fixed now. The toggle only applies to the current buffer. |
| (defun lispy/init-lispy () | ||
| (use-package lispy | ||
| :config | ||
| (defun spacemacs/lispy-off () (lispy-mode -1)) |
There was a problem hiding this comment.
If someone turns off lispy mode, exiting the (state)hook will cause this to fire off and based on this comment, it's better to guard it to avoid unintended issues.
There was a problem hiding this comment.
I guess that's right. Although the situation you linked to cannot happen here, because the hooks are buffer-local. I'll add the guard anyway thanks
|
Would it be possible to use together Lispy layer with evil-cleverparens layer? Related issue: |
|
With this yes
|
|
Great! Thank you. |
@nixmaniack Any suggestions for a new binding? |
|
@justbur That's a tough question! I struggled to find a good spacemacsy alternative while writing that comment hence didn't suggest. Almost everything with two keypress seems to be bound to something. We should ask others I think. @syl20bnr @StreakyCobra @TheBB @tuhdo do you have any suggestion for keybinding for In my case, I use it quite often hence two keypress key should be better. |
|
@justbur hydra is added as dependency of lispy now. |
Thank you! |
|
@nixmaniack can you give a key sequence for a use case using |
|
@syl20bnr
As an example my cursor is somewhere(denoted by (defun test-so|mething ()
...
)I could do (defun test-something ()
...
)
(test-something)|Another use case would be transforming symbol under point to let bound variable using And other would be while browsing through code, select variable under point and evaluate it with The possibilities are endless once you know these commands, and I find it as one of the core bindings of lispy. A thing to note, currently with default spacemacs bindings and hybrid style, you could use |
|
@nixmaniack Here are some ideas
|
|
|
|
@nixmaniack Added the |
|
@justbur 👍 Thanks! |
| (pcase (list (bound-and-true-p holy-mode) | ||
| (bound-and-true-p hybrid-mode) | ||
| spacemacs-lispy-mode) | ||
| (`(t ,x ,y) |
There was a problem hiding this comment.
_ is usally used as a pattern to match anything :-)
There was a problem hiding this comment.
(t ,_ ,_)` matches the same as (t ,x ,y)but doesn't bindxandy`.
There was a problem hiding this comment.
Yep, thanks. I changed it
The toggle works with all editing styles but behaves slightly differently depending on which one is used. In emacs editing style (holy-mode on), the mode is simply toggled. In hybrid (hybrid-mode on) or vim, the mode is on in insert/hybrid state and off otherwise.
|
I tried it but it does not seem to work or I missed something.
|
|
I agree that the idea of "implicit states" can cause some confusion, but using an extra key would completely defeat Lispy's purpose. If what we want is to make it more clear that he is using Lispy state, what about just changing the colour of the spaceline? As it was mentioned, an user that install this layer should by aware of how Lispy works, we shouldn't modify it, IMO. I agree that if this layer were shipped with Spacemacs replacing the current evil lisp state, then it would be very confusing for users, as they don't know how to use Lispy which is much less intuitive. But it's not the case so I don't think we need to worry about that. |
|
Lispy is not about its implicit state, the implicit state is to introduce some kind of Vim state in the Emacs paradigm, think about a state without a state, and it is OK in Emacs way. Lispy is about the functions it provides to manipulate sexp. I will reformulate what I want this way: Spacemacs is an evil distribution and to add a lispy layer officially it (the layer) has to support lispy as a replacement for evil-lisp-state which means what I repeat over and over again since someone mentioned lispy on this repo. I won't repeat it one more time ;-) |
|
Initial request here: #1955 (comment) |
|
I understand what you want, I think. You want consistency and basically the same interface for evil-lisp-state and lispy. This makes sense for some kind of packages. Let's say there's a syntax checking package called You want the same thing with Lisp manipulation. The problem is that the implicit state is important in Lispy and using the same interface as Sorry if I misunderstood what you want @syl20bnr , but anyway, this discussion is going nowhere. |
I don't care, it has to fit the Vim style as well! A layer variable can allow to control this behavior, seriously do I have to repeat the same thing again ? Vim users feel basically naked in insert state when it comes to navigation and manipulation of text, a state is needed for this! No lispy state --> no official layer in Spacemacs. I won't comment on this thread again. |
|
Can we just pretend VIm users do not exist and don't care about this layer i.e. mark it Emacs only layer? |
Spacemacs, as syl20bnr said, is an Evil distribution. I use it with Evil and I'm very interested in using Lispy, as many Evil users are. |
|
Does that mean you want to replace smartparens (current backend of evil-lisp-state) with lispy for vim style? And the same keybinding which enables evil-lisp-state for vim style, will enable lispy for emacs style without switch of the explicit state? For hybrid style, I prefer going emacs style way, no switch of state. |
Thank you, my fear about Spacemacs loosing its identity is real. I'll see what I can do to put back the project on the right track. |
If this is the case, and the way that Lispy has to fit in Spacemacs, there's no value in adding Lispy to Spacemacs because essentially Lispy is just another version of evil-lisp-state with more fancy commands. |
I assumed this since start that lispy is only for emacs style(hybrid for me). |
This is why I want it! As I said lispy is about the commands to manipulate sexps, not the way we activate its state. The activation method can be a layer variable, OMG do I have to repeat again ? :-) |
|
Well, actually the current solution is not bad. Evil users that want to use Lispy in a Emacs editing style way can temporarily switch to hybrid state - this is what I would do. Otherwise they use the familiar |
|
I would appreciate if you answer this @syl20bnr. This would make it more clear in case someone wants to go ahead and implement. Does that mean you want to replace smartparens (current backend of evil-lisp-state) with lispy for vim style? And the same keybinding which enables evil-lisp-state for vim style, will enable lispy for emacs style without switch of the explicit state? |
|
@syl20bnr so, you just want Lispy to be an enhanced version of Probably, a better approach is to enable the implicit state by default in |
@nixmaniack Not really, it means we can replace the whole evil-lisp-state by a lispy evil state activated on
@tuhdo Actually both could leave together in holy-mode, implicit and explicit. |
|
@tuhdo This is the Emacs paradigm which lacks states in conventional insertion of text, not Vim where states are at the root of the paradigm so your idea of half its power is a lot biased. As I said, the activation method is not important both types of users are equaly efficient to manage either implicit state or explicit state. Explicitly switching state for a Vim user == no op, and having an explicit state to manipulate text is what a Vim user expects. EDIT: what I meant here is that in holy mode both way to activate the state can live together because after all Emacs has no notion of state in the first place. But in Vim this is not the case, the state are already part of the game, we have to be compliant with this. |
|
Truth is I don't even notice I press |
|
@syl20bnr the thing is, for an Emacs user, it's very annoying to handle editing states explicitly, and that's why Lispy was created to activate automatically. And I like it much better than mentally switch to LIsp state with a long sequence of key strokes. With Lispy, you need 0 key stroke to get in and out of its editing state. And this is why it was created. If Emacs users want to have modal editing the Emacs way, they can simply use |
So Evil users that prefer
|
@tuhdo I hear you and this is totally fine. Lispy may be the ultimate sexp manipulation backend for Spacemacs thanks to this but it has to fit the Vim way as well. |
@tuhdo Not exactly, actually both methods cancel each other on this particular point. To be in lispy state you have to move the point on the right position first, which is not 0 keystroke ;-) |
That's why I suggest we should leave the way
Well, that's true but as an Emacs user, explicitly manage editing state is unbearable, so that's the reason Lispy does it for them. In the case of an Emacs user, they might want to use other commands in conjunction with Lisp-specific commands i.e. use That's why I suggest to leave Lispy as is in |
👍 vim - explicit ( with |
|
Actually more this:
More on what I said about cancelling each other, from Lispy README (see at the end of this post) we can go to a special place from anywhere, so basically I press You can use plain Emacs navigation commands to get into special, or you can use
These are the few lispy commands that don't care whether the point is |
|
Maybe something like this could be pretty handy:
|
|
Actually, an evil-lispy package is what is being suggested here, and I think it may work pretty well. |
|
Can be part of the layer before being a stand alone package. |
This layer adds the lispy package and makes it available as a toggle on
M-m k.The intention is to provide users of holy-mode (and possibly hybrid-mode) with an alternative toevil-lisp-statefor editing lisp in spacemacs.