(WIP) Add Lispy Layer

[cmccloud]

Thoughts and contributions welcome.

Spacemacs/Lispy Integration

• Add basic mode based dispatch system
• Associate lispy with modes by state
• Add minor modes to dispatch system - waiting to hear abo-abo's thoughts
• Prefer helm for occur
• Create option for dedicated evil state?
• Create spacemacs-lispy-keymap that conforms more closely to evil conventions

Clojure Layer Integration

• Cider keybinds
• Cljr Refactor keybinds

Scheme Layer Integration

Common Lisp Layer Integration

[robbyoconnor]

👍

[sooheon]

The toggle is good, I think it should eventually be changed to the standard of SPC t foo though. The major-mode based dispatch is interesting, but what is the difference between that and a simple hook for the major mode?

Why do you want lispy to toggle on and off by state? What's wrong with having lispy around in normal state, when operations like lispy-raise-sexp or lispy-kill are either exactly equivalent to the smartparens variant or improved? Special mode is activated by entering insert-state at a special point, there is no reason to constantly toggle lispy, unless I'm missing something.

Some of this layer seems highly opinionated, and I can't see the benefit of some customisations. What is the need for clojure/scheme/cl specific bindings, when functionality is really orthogonal to what those major mode layers offer? Rebindings like C-f to lispy-forward and C-d to lispy-backward seem unnecessary, and is not something someone who just wants lispy would know.

I think the lispy layer should offer lispy itself inside spacemacs in a discoverable way, and the only real opinionated customizations should be where it happens to conflict in some way with evil, smartparens, etc.

[cmccloud]

@sooheon I agree with a lot of your suggestions - right now this is little more than my configuration, and would be almost completely rewritten before becoming a proper layer. Maybe i shouldn't have included a PR and limited this to just a discussion, but seeing code always helps me so I thought it might be useful.

I'll remove my customization to make my intentions clearer here.

[cmccloud]

@sooheon but I disagree about the value of integration. I think that a layer should be more than just another way of installing a package; if someone wants to setup lispy in spacemacs, it's as easy as adding it as an additional package, it works perfectly right out of the box.

[sooheon]

@cmccloud It is a good point that because default setup is easy, we can afford to be a little more opinionated in integration. Just out of curiosity, which lispy-key-themes do you have included in lispy-mode-map? And what do you think would be a good default? I use (special paredit c-digits), and think that's why some of your hard keybindings seem out of place to me.

[mbertheau]

@cmccloud I wanted to try out lispy and added it to dotspacemacs-additional-packages, but I got a lot of errors on startup and lispy-mode also doesn't work - I tried j in insert state with point before or after an opening paren, and it just inserted j.

Compiling file /home/markus/.emacs.d/elpa/lispy-20150911.225/elpa.el at Mon Sep 14 10:33:59 2015
Entering directory `/home/markus/.emacs.d/elpa/lispy-20150911.225/'

Compiling file /home/markus/.emacs.d/elpa/lispy-20150911.225/le-clojure.el at Mon Sep 14 10:33:59 2015
le-clojure.el:25:1:Error: Symbol's function definition is void: defhydra

Compiling file /home/markus/.emacs.d/elpa/lispy-20150911.225/le-lisp.el at Mon Sep 14 10:33:59 2015

Compiling file /home/markus/.emacs.d/elpa/lispy-20150911.225/le-scheme.el at Mon Sep 14 10:33:59 2015

Compiling file /home/markus/.emacs.d/elpa/lispy-20150911.225/lispy-inline.el at Mon Sep 14 10:33:59 2015

Compiling file /home/markus/.emacs.d/elpa/lispy-20150911.225/lispy-tags.el at Mon Sep 14 10:33:59 2015

Compiling file /home/markus/.emacs.d/elpa/lispy-20150911.225/lispy.el at Mon Sep 14 10:33:59 2015
lispy.el:5420:1:Warning: Unused lexical argument `e'
lispy.el:6482:1:Warning: `"j"' is a malformed function
lispy.el:6482:1:Warning: `"k"' is a malformed function
lispy.el:6482:1:Warning: `"z"' is a malformed function
lispy.el:6482:11:Warning: reference to free variable `lh-knight'
lispy.el:6484:8:Warning: reference to free variable `lispy-knight-down'
lispy.el:6485:8:Warning: reference to free variable `lispy-knight-up'

In end of data:
lispy.el:6890:1:Warning: the following functions are not known to be defined:
    cider-debug-defun-at-point, projectile-global-mode, defhydra

So unless I'm missing something I think there could be great value in a lispy layer.

Currently for modes with a lisp-like syntax the single-character keys are still bound to the word and line-based editing commands from vim, which is not optimal for lisp syntax.

[cmccloud]

@mbertheau This is something that was recently introduced to lispy - the temporary fix is to both recompile and reload lispy.el.

1. Spc h L - navigate to lispy.el
2. Call byte compile file with prefix argument - M-x C-u byte-compile-file - select lispy.el.
   Sometimes you have to update lispy.el on disk first (making a harmless change and saving the file seems to work).

If I get some free time I may reopen the PR and see about automating the process, but for the moment I'm not really able to work on it.

[sooheon]

@mbertheau @cmccloud The problem also reoccurs when you update lispy. The process can be annoying, so a temporary fix is to put (spacemacs/load-or-install-package 'hydra) in dotspacemacs-init, which is really hacky, but stops the issue reappearing.

[cmccloud]

@sooheon Thanks - that's extremely useful to know. Do you think putting that inside of the :init block of the (use-package lispy) call would have the same effect? e.g.

(use-package lispy
  :init (spacemacs/load-or-install-package 'hydra)
  :config (......))

[sooheon]

I think I added that after trawling through the spacemacs init process for a bit, can't remember why it had to go in the global init and don't see any reason why it shouldn't work in there right now... would have to try it out though.