Do we actually want evil-unimpaired

[plexus]

I only recently realized that through evil-collection we're also pulling in a bunch of keybinds for "evil-collection-unimpaired", a partial reimplementation of vim-unimpaired

  (evil-collection-define-key 'normal 'evil-collection-unimpaired-mode-map
    "[b" 'evil-prev-buffer
    "]b" 'evil-next-buffer
    "[e" 'evil-collection-unimpaired-move-text-up
    "]e" 'evil-collection-unimpaired-move-text-down
    "[l" 'evil-collection-unimpaired-previous-error
    "]l" 'evil-collection-unimpaired-next-error
    "[L" 'evil-collection-unimpaired-first-error
    "]L" 'evil-collection-unimpaired-last-error
    "[q" 'evil-collection-unimpaired-previous-error
    "]q" 'evil-collection-unimpaired-next-error
    "[Q" 'evil-collection-unimpaired-first-error
    "]Q" 'evil-collection-unimpaired-last-error
    "[n" 'evil-collection-unimpaired-previous-SCM-conflict-marker
    "]n" 'evil-collection-unimpaired-next-SCM-conflict-marker
    "[p" 'evil-collection-unimpaired-paste-above
    "]p" 'evil-collection-unimpaired-paste-below
    "[P" 'evil-collection-unimpaired-paste-above
    "]P" 'evil-collection-unimpaired-paste-below
    (kbd "[ SPC") 'evil-collection-unimpaired-insert-newline-above
    (kbd "] SPC") 'evil-collection-unimpaired-insert-newline-below)

Seems there's also a setting to disable this

(defcustom evil-collection-want-unimpaired-p t
  "Whether to enable unimpaired style bindings globally."
  :type 'boolean
  :group 'evil-collection)

I've never used any of the above bindings, and looking at them I think few would be useful to me, so I'm leaning towards disabling this by default. That also opens up [ and ] as potential future leader keys for Corgi. We could use them to bind our own "pairs" of commands that are more relevant to a clojure/lisp workflow. (In vanillla vim these navigate to the previous/next {...} section, which seems mostly useful for curly-brace languages.)

If we do want (some of) the above I would still prefer to disable the auto-setup, and to instead bind them through corkey, so they are in one place with the rest and more discoverable.

[oxalorg]

Yeah I rarely use any of the unimpared commands, I think it's fine to get rid of them. Having all keybindings in Corkey is the dream ;)

[theophilusx]

I don't tend to use them either. My only concern about removing them is the possible impact on users who have come from vim and users who have been using evil for a while who may have become accustomed to those bindings (it is a fairly standard evil config). Don't think this is a big issue - we probably just need to be explicit in the manual and describe how to re-enable them in personal config file.

[plexus]

They're not vanilla vim, they're provided by a package. In fact this overrides the vanilla vim bindings for [ and ] as mentioned. I want to avoid overriding vanilla vim bindings, with a few notable exceptions (e.g. L and H for prev/next sexp). For non vanilla bindings I think anything is fair game.

Generally from Corgi's perspective any binding (including vanilla emacs bindings) that isn't explicitly set in corgi-keys only works by accident. We want to get away from this "I just discovered this whole set of bindings that some nested package created", all bindings that matter should be listed in one place: corgi-keys.

That said I'm somewhat starting to come around to these. Especially the "cycle through buffers" (]b and [b) I think is very useful. I mainly use SPC TAB or just look for the buffer with SPC b b, but this is much more convenient for a somewhat recently used buffer.

The "cycle through errors" thing is probably useful for clj-kondo users. I can also see myself using it with (set! *warn-on-reflect* true) to cycle through reflection warnings.

So I would consider rolling (a subset of) these bindings into corgi-keys. That does double the amount of leader keys that corgi "owns" (SPC, ,, [, and ]), and begs the question how we are going to make best use of that additional key-binding-space real estate. The symmetry is nice, and could actually work great for more sexp-aware navigation, e.g. we don't have bindings at the moment for going up/down sexps.

Generally these commands would be even more useful if they could repeat, e.g. ]bbb = go back three buffers, maybe something to think about in the context of #13, although this could create conflicts with other one-key commands. Maybe just making sure they work with . makes more sense: ]b...

[theophilusx]

For me, the '.' to repeat the last command is something I use often. Perhaps wrong, but for me, rather than ]bbb I'd probably do 3]b (although most likely I would just do ]b..).

I also started using tabs after they were added as part of Emacs. In evil mode gt/gT are defined for next/previous tab. Weirdly, there is no binding to create/delete tabs from the tab-bar. In my corgi setup, I've added "SPC T c" for create and "SPC T d" for delete and use gt/gT to go to next/prev tab.

I would tend to agree that a subset of the bindings from unimpaired would be useful. Obviously, we can just add what we want using unimpaired as a guide rather than enable the evil-collections bindings.

[oxalorg]

I completely forgot but I used to quickly move around "chunks" of changes in vim.

Added this to my corkey config

 (normal|visual
  ;; ("I" "Start insert on forms" evil-cp-insert-at-beginning-of-form)
  ("[" "unimpared behind"
   ("c" "Next hunk of git change" git-gutter:previous-hunk))

  ("]" "unimpared ahead"
   ("c" "Next hunk of git change" git-gutter:next-hunk))