noctuid / lispyville

lispy + evil = lispyville
GNU General Public License v3.0
313 stars 23 forks source link

[Request] evil-cleverparens insert functionality #29

Open jojojames opened 6 years ago

jojojames commented 6 years ago

Just thought I'd request this from evil-cleverparens.

Insert

When entering insert-state via i in a situation where the point is between a round opening parentheses and a symbol, evil-cleverparens will automatically insert a space and then move the cursor back for you. The rationale is that when you are in this situation, it's much more likely that you are inserting a new word at the beginning of the list rather than modifying the beginning of the current head of the list, and therefore it would be nice if the two words were already separated so that your auto-completion mode can do its thing. This behavior can be disabled by setting evil-cleverparens-use-regular-insert to t.

May or may not be appropriate for this package but that was one thing I missed transitioning over from evil-cleverparens to lispyville.

noctuid commented 6 years ago

I could add this as an option or new key theme (probably off by default). It's probably also worth pointing out that this is less of an issue if you use lispy for navigation as you will usually get directly to the prior paren already in insert/emacs state. If you are after an opening paren, SPC will also insert a space after the point instead of before.

jojojames commented 6 years ago

That's be great to have it as a key theme.

As for lispy itself, it was on my todo list at some point to check it out, but then it seemed like another 'mode' to have to manage in and out of. The vim ones are enough for me so I just use lispyville as a more stable evil-[clever/smart]parens.

noctuid commented 6 years ago

Sorry for the late response. I've gone ahead and committed what I have (no tests or documentation yet). I wanted to make it work in visual block mode, but I'll look into that possibility later. For consistency it just won't do anything from visual state for now. Unlike cleverparens which defines new insert/append keys, the insert key theme just uses the insert enter/exit hooks. Let me know if you have any issues or suggestions.

noctuid commented 6 years ago

As for lispy, usage of lispy is kind of orthogonal of usage of evil; they don't really get in each other's way. I really recommend looking into it if you get the chance; even the basic operations can make lisp editing a lot more efficient.

jojojames commented 6 years ago

Let me know if you have any issues or suggestions.

Cool, I'll try it out and comment if need be.

I really recommend looking into it if you get the chance; even the basic operations can make lisp editing a lot more efficient.

Yeah, I have some uncommited lispy code in my dotemacs at your suggestion. Mostly trying to futz around with the single-key lispy bindings to make them a little more vim-y.

One thing (polish item) that I'd like is an explicit tag change (or at least some way to change the evil tag when it gets into lispy-state). I know it's implicit for emacs but it just seems a little weird for the mode-line to say 'insert' (or whatever the default insert state tag is) when it's really in implicit-lispy state.

That's something I like about https://github.com/sp3ctum/evil-lispy. You can change its tag since it's tied to a new evil state.

noctuid commented 6 years ago

I've personally completely change my own lispy keybindings to be more like vim (e.g. o to switch to other delimiter, d for delete, y for copying, p for paste, / for occur, etc.). I haven't provided anything like that for this package because I think it should be added as a key theme to lispy if anyone wants rebindings like this. My personal setup is pretty heavily modified in other ways and isn't as all suitable as a general vim key theme, but discussion on the evil-collection or lispy repo about making a vim/evil key theme might be useful in the future.

I don't use evil state tags at all personally; I just go by the color/shape of the cursor. Even if I did, I don't think it makes sense to add an extra state for lispy just for this purpose. It doesn't make sense to think of lispy's special exactly like an evil state. Evil states are manually changed which is why visual indication is required to distinguish between insert and normal state for example. Since lispy is based entirely on the location of the point (or whether there is an active region), it's always clear whether lispy's keybindings are active. Adding a new state just to show when lispy's keybindings are active would be a pretty poor workaround (e.g. it would require code to automatically switch between insert and the lispy insert states).

If you still would rather have a visual indicator for lispy, I can add it as an entirely separate modeline indicator if you'd like. I'd rather do that than try to reuse evil's tags for this purpose.

jojojames commented 6 years ago

(e.g. o to switch to other delimiter, d for delete, y for copying, p for paste, / for occur, etc.).

Yeah, I've tried to do some rebindings to achieve something similar. I'll post something on evil-collection to see if a new key-theme can be created.

If you still would rather have a visual indicator for lispy, I can add it as an entirely separate modeline indicator if you'd like. I'd rather do that than try to reuse evil's tags for this purpose.

That's be great.

noctuid commented 6 years ago

I've added a function that can be used in the mode line or as the lighter. The face and text are customizable. See here for details.

jojojames commented 6 years ago

For insert, I get:

lispyville-insert-enter: Symbol’s function definition is void: lispyville--after-left-p

noctuid commented 6 years ago

Thanks; it should be fixed now.

jojojames commented 6 years ago

Thanks works for me. I've created a topic for the lispy key theme.

noctuid commented 6 years ago

Great. I'm going to leave this open until I've added documentation/tests. I'm also going to add an option to insert a space before the point when inserting just before a closing delimiter and potentially add support for visual block state.