[enhancement] issues using lispyville in non-lispy modes

[JJPandari]

Continuing discussion in #53

• problem: lispyville-delete lispyville-up-list automatically prettifies code, pulling things after { to the same line, which is unwanted. (Not using prettify key theme but binding lispyville-prettify or evil-indent depending on major mode fixes evil-indent.)
  idea: Maybe provide option to not prettify anything after delete etc.? Or, option to override the internal prettify mechanism with normal indent?
• problem: y y on console.log(`hello, ${name}`), when pasting, the second ` will be missing.

[yuhan0]

Are you referring to the closing delimiter } being pulled to the same line as the last item? That's the default behaviour in lispy itself, which you can customize globally by setting lispy-ignore-whitespace to t.

It might be a good idea for lispyville to keep a list of known lisp modes and override certain settings buffer-locally for non-lisp modes.

Related snippet from my current config:

(setq lispyville-lisp-modes
  (append lispy-elisp-modes
          lispy-clojure-modes
          '(scheme-mode racket-mode lisp-mode common-lisp-mode hy-mode)))

(evil-define-key 'normal lispyville-mode-map
  [remap evil-indent]
  (lambda () (interactive)
    (call-interactively
     (if (memq major-mode lispyville-lisp-modes)
         #'lispyville-prettify
       #'evil-indent))))

[JJPandari]

@yuhan0

being pulled to the same line

yes.

lispy-ignore-whitespace says it affects lispy-right, as I experiment, setting it to t does prevent lispyville-up-list from prettifying. However lispyville-delete still prettifies.

---

BTW, it's easier to conditionally remap evil-indent using general.el :

;; https://github.com/noctuid/evil-guide#preventing-certain-keys-from-being-overridden
(general-override-mode)

(general-define-key
 :keymaps 'override
 :prefix "SPC"
 :states '(normal motion visual)
 ","
 (general-predicate-dispatch 'evil-indent
   ;; pred def ...
   (memq major-mode lispyville-lisp-modes) 'lispyville-prettify))

Or use general's :predicate if not binding the 2 definitions in the same map.

[noctuid]

Not sure if we should really bother making lispyville working in non-lispy modes

The main thing I would support in non-lisp modes would be the safe operators. They are written in a fairly generic way and could work with custom delimiter pairs. Things like slurping/barfing and things that rely on lispy wouldn't be supported for the most part (though lispy does support some functionality in non-lisp modes, like eval). I've considered adding a separate minor mode for non-lisp modes.

The function, comment, and string text objects (and corresponding motions) will be fully generic and moved to another package (I basically have them working already in a major-mode agnostic way).

However lispyville-delete still prettifies.

Yeah, there is code for this directly in lispyville-delete at the moment. I agree that the auto-formatting/prettification should be configurable in some way.

[JJPandari]

Just heard about the incremental parser tree-sitter and its emacs bindings, on Emacs-China. Excited about how we can make lispy{,ville} available everywhere someday with tools like these. Dynamic module seems to be making many things possible.