M-m is a common keybinding and should not get redefined about lispy HOT 5 CLOSED

M-m calls back-to-indentation which is useless when lispy-mode is on, } inserts [] which should
be enough to replace the default [ and ]. On the other hand, without efficient ways of getting into special, like M-m or ], lispy is useless and you might as well just use Paredit.

I've covered ways of re-defining the global bindings of lispy-mode in the README.

If you are bothered enough by the default bindings, you can drop a few lines to change them in your config. I don't want to cripple lispy-mode preemptively: you can unbind M-m yourself, with a way to fix it that's best for you.

But I can't know in advance what shortcut is the best for you for go-to-paren-backwards, go-to-paren-forwards, and mark-current-symbol. I just choose bindings that are reasonably ergonomic and reasonably free. I say "reasonably" because all the good bindings were already taken 30 years ago.

from lispy.

Sorry for not getting back to this earlier, this fell through the cracks. Why do you consider back-to-indentation to be useless when using lispy? At least when not in special positions I don't see a good alternative to move to the beginning of the line.

I agree that it's a fine balance to strike between making the plugin useful so it's easy to use and not breaking existing functionality (and the official Emacs policy for this a bit too rigid). But I think it does pay off to try to minimize these kinds of conflicts as much as possible to minimize the amount of needed customization code. What about providing either an option you can set in customize or a function to not add "conflicting" key bindings that automatically evolves with new bindings?

from lispy.

Why do you consider back-to-indentation to be useless when using
lispy? At least when not in special positions I don't see a good
alternative to move to the beginning of the line.

Well, there's C-a: lispy-move-beginning-of-line:

• forwards to move-beginning-of-line
• when already there, forwards to back-to-indentation

Still, line-based navigation isn't very useful for LISP.

What about providing either an option you can set in customize or a
function to not add "conflicting" key bindings that automatically
evolves with new bindings?

I'll think about this. Seems like a hassle and there would be
hairsplitting over which bindings are "conflicting". I think it would
be much more productive if people just put something like this in
their personal config:

(mapc
 (lambda (x) (define-key lispy-mode-map (kbd x) nil))
 '("M-m" "M-i"
   ;; more stuff
   "[" "]"))

It's really not that much config. Looks even less if you one-line it with O :)

from lispy.

Ok, I think we're hitting a philosophical difference there and I see lispy as something a bit more lightweight than you intend it to be. I'm using it to make common editing tasks easier but not to turn Emacs into something like a structured editor where code will always parse.

I'm using this one now:

(after-loading 'lispy
  (dolist (x (list "M-m" "M-i" "}"))
    (define-key lispy-mode-map (kbd x) nil))
  (lispy-define-key lispy-mode-map (kbd "[") 'lispy-backward)
  (lispy-define-key lispy-mode-map (kbd "]") 'lispy-forward))

Feel free to include it if you think this is sufficiently useful for other people.

from lispy.

structured editor where code will always parse

You don't have that? Gosh, what a stone-age thing to do:)

(lispy-define-key lispy-mode-map (kbd "[") 'lispy-backward) (lispy-define-key lispy-mode-map (kbd "]") 'lispy-forward)

These two are strictly worse than hjkl.

from lispy.