This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-06
Channels
- # aleph (79)
- # bangalore-clj (3)
- # beginners (49)
- # boot (74)
- # cider (10)
- # cljs-dev (21)
- # cljsrn (2)
- # clojure (105)
- # clojure-berlin (1)
- # clojure-brasil (1)
- # clojure-dusseldorf (1)
- # clojure-korea (1)
- # clojure-poland (3)
- # clojure-russia (38)
- # clojure-spec (146)
- # clojure-uk (20)
- # clojurescript (70)
- # cloverage (1)
- # component (1)
- # core-async (23)
- # css (16)
- # cursive (22)
- # datascript (1)
- # datomic (22)
- # defnpodcast (6)
- # emacs (60)
- # events (1)
- # hoplon (94)
- # jobs (1)
- # jobs-rus (13)
- # luminus (11)
- # off-topic (11)
- # om (48)
- # onyx (5)
- # proton (7)
- # re-frame (87)
- # reagent (39)
- # rethinkdb (1)
- # ring-swagger (14)
- # rum (6)
- # specter (14)
- # untangled (105)
- # vim (6)
- # yada (22)
Does anyone here know if vim-sexp has support for paredit.vim style paren balancing? e.g it doesn't let you delete a paren that would cause unbalanced code?
I tend to use db
quite a lot, with paredit.vim this would only delete back as far as it could without causing unbalanced parens, which I found quite nice.
It's possible there is a more optimal way to do what I'm doing though!
I found that kind of feature broke all the time.
I tend to just daf
or hit (
until I can dae
Ah, daf
is much more optimal. I agree by the way, it did break a lot.
It's slightly annoying to me to suggest you change your workflow, so I'm sorry. Overall, paredit doesn't suit vims editing model. Maybe neovim will bring the events needed to make everything work someday? No idea if I want them to necessarily (too unvim?) This is a small battle for today though.