Is there a position regarding supported Emacs versions for corgi? Emacs 28.1 has been released and is what I'm running. However, most distros will be shipping with Emacs 27.

Asking so that I know what versions of Emacs I should test with when I develop a fix, enhancement or extension.

SPC b b at the moment shows a buffer list which is populated by all kinds of buffer like:

Most of these aren't very useful. When moving around in the project I typically only want to see buffers related to the project to switch quickly.

I think Doom emacs differentiates them as "Real" and "Unreal" buffers.

A real buffer is a useful buffer; a first class citizen in Doom. Real ones
should get special treatment, because we will be spending most of our time in
them. Unreal ones should be low-profile and easy to cast aside, so we can focus
on real ones.

https://github.com/hlissner/doom-emacs/blob/9cab6a6fd9e43b6e95dbfa31a65b7119b7b11b0f/core/autoload/buffers.el

Any thoughts about this?

I just noticed the following in the corky-keys.el file and I'm not sure I really understand what is going on.

("," "Project specific leader key"
  ...
   ("l" "Link to REPL"
    ("p" "Link with project" :link-repl/project sesman-link-with-project)
    ("b" "Link with buffer" :link-repl/buffer sesman-link-with-buffer)
    ("d" "Link with directory" :link-repl/directory sesman-link-with-directory)
    ("l" "Link least specific" :link-repl/least-specific sesman-link-with-least-specific)
    ("u" "Unlink" :link-repl/unlink sesman-unlink))
  ...
)

and in the corgi-signals.el file we have

:link-repl/project sesman-link-with-project
:link-repl/buffer sesman-link-with-buffer
:link-repl/directory sesman-link-with-directory
:link-repl/least-specific sesman-link-with-least-specific
:link-repl/unlink sesman-unlink

under the cider-mode section. My questions are

• What does the construct ":link-repl/project sesman-link-with-project" do i.e. is sesman-link-with-project an argument for the :link-repl/project signal?
• This is a cider specific signal, but is defined in the corgi-keys.el file with the ',' prefix and no (obvious) linking to cider mode at that level. How does this work with other modes when it has such a mode specific definition in the keys file?

Finally, I also noticed the following definition at the end of the corgi-signals.el file

(dired-mode (:toggle/read-only wdired-change-to-wdired-mode))
 (wdired-mode (:toggle/read-only wdired-finish-edit))

Are these correct? They look like definitions to move in/out of wdired mode rather than doing read-only (not really sure what read-only means in a dired context). Is this simply to make :toggle/read-only 'mean' something in dired mode?

When no major mode is active, the Corkey key bindings are not active, and you need to fall back to built-in Emacs bindings.

I posted this on the Corgi channel on the lambda island discord, reposting it here for reference and visibility. At some point this will have to make it into the docs.

Corgi has the opportunity of a fresh start, we have so far been relatively conservative in adding bindings. Our set of key bindings will grow, but we want it to grow in a reasoned way. What follows are guidelines to help decide if a certain key binding should be included with stock Corgi.

• we start from vanilla vim as a baseline, we try hard not to redefine a vanilla vim binding (we generally get these from evil, so we don't typically define these ourselves)
• two exceptions to that:
  • it's a trade-off that is really worth it for clojure devs, e.g. having </>/L/H as single-character commands (barf/slurp/previous sexp/next sexp) provides two orders of magnitude more value to a clojure dev than shift text left/right and top of buffer/bottom of buffer
  • in a certain mode there's something that is conceptually closer to the intent of the vim command, e.g. in dired-mode i switches to wdired-mode. You can still think of it as "insert"
• keys that are not bound in vanilla vim are fair game, but very few (if any) single-character keys are still available
• SPC and , are two leader keys where we put most of our bindings, with SPC being general bindings that work more or less the same anywhere, and , being more mode-specific/language specific behavior
• Within these bindings we care about
  • Good consistent categories: SPC f is all about files, SPC j is all about jumping
  • Good mnemonics: SPC f f = find file, SPC j c is Jump to last Change, etc
  • Not nesting too deep, we have a big space with just leader+two characters, we should rarely have to go three characters deep. (we already have some exceptions, like SPC f e i, and these might move to SPC e i (Emacs Init file)
  • Consistency across modes, if , x y does something in a clojure file, it should not do something wildly different in a JS file
  • discoverability is a big goal here, you can press SPC or , and wait for which-key, and explore and learn Corgi's bindings that way
• vim has some other "leader" keys, e.g. g is a prefix for an amalgamation of things, it's not using the whole space so there's some room in there to add our own
• according to some docs I find [ and ] were to navigate to previous next curly. Maybe that was in original vi, it seems in modern vim they are also prefix keys witth quite a lot of bindings under them. I'm not sure to what extent evil copies these, but currently by loading evil-collection we also get evil-collection-unimpaired which (re-?)binds a bunch of these. There's an open issue for this, we may drop evil-unimpaired and take ownership of that space ourselves.
• Any bindings that are not vanilla vim, and not explicitly defined by corgi-keys, are working by accident, they are not part of Corgi's interface and are fair game to rebind in future versions. This includes all of Emacs' default bindings and any bindings introduced by packages
• If there are Spacemacs (or Doom or whatever) bindings that people particularly pine for then they are free game to be added, but they have to adhere to this policy. In particular spacemacs bindings are often too deeply nested, and inconsistent across mode, and often lack good mnemonics, so for each binding someone will have to make a case why we should add it
• In summary, we cater for vim users first, Spacemacs users second, "legacy" emacs users third, while trying to learn from the mistakes of Spacemacs, so that we can end up with a set of bindings that are consistent and intuitive and "good" (for some value of good) in their own right

Corgi is meant to be a complete but minimal base install. Out-of-the box using the sample config you should have a comfortable editor experience that you can totally just use as-is, but it's not going to have every bell and whistle.

Most people will add several, perhaps dozens, more packages, and includes snippets from left and right to make their config their own. This is how people in Emacs land have always done it, and part of the goal of Corgi is to promote that again. To take the boilerplate out of your emacs config, so that was is actually there is useful stuff that you put there yourself, and that you can understand and own.

But as a new user who arrives at that point it can be unclear what kind of things they can even put in there. Ideally there would be a place where they can find "the next steps", common packages, settings, tweaks, bindings, that people in the community have personally found helpful.

I'm really not sure what the best place or format for that would be. I don't think I want it inside the official manual, as that means we are now in the business of curating and vetting these snippets. It turns us into a gatekeeper. Generally any approach where a single person curates I think is not suitable, since then it comes down to a single person's taste again.

On the other hand curation, or at least some kind of filtering system, is essential, otherwise we might as well just point people at the emacs Wiki.

So in mind the ideal would be 100% open, with no gatekeeping, anyone can add things to the collection. There should be a way to discuss, so people can say "I'm using this too", or "this doesn't work for me", or "I prefer to do something similar but slightly different". And there should be a way to vote/endorse, so you can find the things that actually are widely used/endorsed. It should also be slow moving/timeless, I don't want it to be like reddit or the announcements channel on clojurians, where you need to check every day or things drop off the page and you missed them.

Maybe we make a Corgi topic on ClojureVerse? People can post and discuss as they like, and vote with likes or emoji reactions, and the ones that reach a certain threshold we pin to the top of the channel.

I am using a mac book pro 2015 with a emacs-plus@28 installation. I started with a fresh install of emacs as described in the corgi repository. I copied the sample config files to a clean ~/.emacs.d folder. When emacs starts up, I get the following error:

Warning (initialization): An error occurred while loading ‘/Users/thechetan/.emacs.d/init.el’:

error: Could not find package string-edit. Updating recipe repositories: (corgi-packages org-elpa melpa gnu-elpa-mirror nongnu-elpa el-get emacsmirror-mirror) with ‘straight-pull-recipe-repositories’ may fix this

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace. Disable showing Disable logging

1. Running the M-x straight-pull-recipe-repositories doesn't fix the issue
2. Changing the straight.el url in bootstrap.el doesn't fix the issue

When I do a fresh install using the same init.el you provided on the documentation page, I get the error:

error: Could not find package consult-selectrum in recipe repositories: (corgi-packages org-elpa melpa gnu-elpa-mirror emacsmirror-mirror)

I want to replicate this behaviour in corkey

(evil-define-key 'insert 'global
  (kbd "9") "("
  (kbd "0") ")"
  (kbd "(") "9"
  (kbd ")") "0")

I have tried the following:

(normal|visual ...)
(insert
 ("0" "Open bracket" ")"))

and

(normal|visual ...
 (insert
  ("0" "remap" ")")))

But both didn't work.

Maybe

;; = 'normal' | 'insert' | 'visual' | 'emacs' | 'motion'

state should have an empty value for the topmost form, so that others can be nested inside it

eg:

(""
  (normal|visual ...)
  (insert
   ("0" "remap" ")"))))

In a Clojure buffer, after doing a corgi/cider-quit-all, only bindings that are shared across all modes still work. You need to reload the file before you can use Clojure-specific bindings again.

In the evil-multi-leader.el file we have this line

(with-current-buffer (find-file-noselect "/home/arne/emacs-profiles/lesser-evil/leader-bindings.el")

which should ideally be:

(with-current-buffer (find-file-noselect file-name)

Just trying to go through the code to understand it a bit better, I'm not yet sure how this function is being used though!

Not everyone has a convenient location of the Esc key on their keyboard, requiring a rebinding of keys in the OS or a slower transition between insert and normal mode.

Consider adding the evil-escape package to provide a simple mechanism to bind a two-character key binding as an alternative to pressing the Esc key.

(setq-default evil-escape-key-sequence "jk")

Reference

• https://github.com/syl20bnr/evil-escape

Do you have any recomendations?

I'm starting to think it would make a lot of sense to move all Corgi stuff to its own dedicated Github organization. We already have several different repos, and I think the time is right to start splitting some of the packages into their own repo.

The situation today

• lambdaisland/corgi: this repo, landing page, docs, sample config
• lambdaisland/corgi-packages: straight.el package repo (really just this one file), plus a number of the packages themselves
• plexus/plexmacs A few other custom packages that we pull in in Corgi

Packages in this case come in two flavors, there are "true" emacs packages in the traditional sense that implement a specific feature or API, and there are what I've been calling "meta-packages", that consist of a bunch of use-package declarations and bits of glue code. The latter are really what make Corgi Corgi.

The distinction is important to me because I'm trying to apply a separation of Mechanism and Policy in Corgi. Most Emacs packages provide both Mechanism (commands) and Policy (key bindings, hooks). Big Spacemacs like configs intertwine mechanism and policy so tightly it's impossible to reuse any of it without buying in wholesale. With Corgi we want almost everything to be "plain" packages that people can use as they please, and a fairly thin layer of policy (choice of packages, key bindings, hooks and other bits of glue), that people can take or replace/tweak to their liking.

"True" packages (mechanisms), which I think would all make sense as separate repos.

• clj-ns-name: Rename buffers according to their Clojure namespace name (in plexmacs)
• walkclj: Convenience API to traverse parseclj results, used by clj-ns-name, based on treepy (in own repo)
• pprint-to-buffer: Like cider-pprint-eval-last-sexp, but for Emacs Lisp (, e p in Corgi) (in plexmacs)
• Corkey: Corgi's key binding layer, probably the most defining feature of Corgi. Could use the added visibility that a top-level repo would give it. Also contains Corgi's default binding files (policy), if we split this into its own repo then I would take those out. Currently based on which-key but contemplating re-implementing that part from scratch.
• corgi-stateline: Change the modeline color to indicate the current evil state
• corgi-cider-indicator Currently still lumped in with corgi-clojure but I'm splitting this out. Add a colored indicator to the modeline for each connected REPL that evaluations in the current buffer go to, indicating if it's clj/cljs/bb, and showing project/host/port if different from the current project.
• cider-eval-pprint-register Just a single function and currently lumped in with clojure-mode, but generally useful. Could perhaps also go upstream to CIDER if they'll take it.

Note that each of these could in theory be submitted to MELPA, but I have no intention of doing so. We use straight which is superior in every way and doesn't involve gatekeeping and nitpicking. But if people find them useful and want to make them more broadly available that way they are welcome to submit them, and we'll consider minor patches to appease MELPA's arbitrary policies.

Meta-packages (policy)

• corgi-defaults typical "better defaults" package
• corgi-editor bit of a mish mash and some of it will be split out (see #18), but basically it's the answer to the question "I'm new to Emacs, what handful of packages would make my life a lot easier?". It provides the spacemacs-y feel of Corgi with evil/evil-collection/which-key/winum, small quality of life things like undo-fu/avy/dumb-jump/goto-last-change/string-edit/expand-region/xclip, bigger dev environment features things like projectile and company-mode, and editor features like smartparens/evil-cleverparens/rainbow-delimiters/aggressive-indent
• corgi-clojure: clojure-mode, CIDER, clj-ns-name, and then a bunch of CIDER monkey patches, mainly to make its REPL selection more sensible. Perhaps some of it could make it upstream, but not sure if it would be welcomed. This is all dear to me though, it's the result of years of trying to remove friction from my Clojure workflow, and is I think a major selling point for Clojure devs to adopt Corgi.
• corgi-emacs-lisp mainly custom commands that mimic some of the conveniences of CIDER, so that working in elisp feels the same as working in Clojure. E.g. have a thread-first/thread-last refactoring (, r t f / , r t l), eval-pprint, highlight the evaluated form. Have jump-to-definition and show doc of symbol (via elisp-slime-nav)
• corgi-commands: junk drawer of commands that we need to mimic certain spacemacs features (around buffer/window management), and some corgi specific things (open key binding/signal file)

These are all "policy" packages, they are basically the boilerplate that goes into a typical emacs config. You can pull them in as packages, or just copy them wholesale into your own config and tweak them from there. I think keeping these together in corgi-packages makes sense.

It's still important to me that these are just packages, that it's packages all the way down. These policy packages are deliberately opinionated, we resist the urge to provide options or configuration for them, but we encourage people to modularize similar slices of their own configs, to encourage a marketplace of ideas.

Is there a (suggested) way to browse through the functions of a project in corgi?

Hello,

First, I want to say that your approach here really resonates with me. It feels very selective and light to the touch compared to Spacemacs or Doom, while being a great basis to customize. To that end, I'd like to throw out a couple of packages that are lighter weight than your current choices and might be interesting to you. If you've already considered them, then no problem.

For completion frameworks, Selectrum or Icomplete Vertical, along with prescient or orderless.

Here is a comparison of Selectrum vs Ivy. Icomplete Vertical shares a lot of the same advantages, but is even more modest in scope.

There's also a whole section about all of the extensions that are available to extend either of these options, since they're both based on the built-in completing-read. This ecosystem of packages are great because they're all usable with vanilla Emacs outside of any particular completion framework.

You also may be able to replace projectile with the built in project.el. Manuel Uberti wrote a couple posts about it recently.

Corgi aims to be a fairly minimal config, while at the same time being fairly complete when it comes to Clojure development. You should have a setup out of the box that gives you the amenities you would expect from a Clojure editing environment. But what does that mean, what do we include out of the box, and what don't we? I'm somewhat torn on some of these choices. Below I'll try to lay out my mental framework of how I'm thinking about these choices.

Currently we include clojure-mode, CIDER, clj-ns-name, and cider-connection-indicator. We still have clj-refactor listed as a dependency in corgi-clojure, so it gets installed, but we don't do anything to enable it (the dependency is a leftover that was intended to be removed).

So currently we don't include clj-refactor, clj-kondo, clojure-lsp, even though a lot of people are using these, and clearly get value out of them. The reason is that I personally don't use linters, and I've tried clojure-lsp and found it too immature. High CPU usage, a few times I had to kill Emacs. I've also had plenty of issues with clj-refactor in the past, although that's been a few years and I feel like it's pretty stable now.

The trade-off we need to think about is that each of these packages adds significant complexity, which means higher resource usage, more things that can go wrong, more layers to wade through when troubleshooting, and more things the user needs to learn about. That complexity can only be justified if we get enough value in return. key phrase: return on complexity

This value I think can be split into "passive" value, and "active" value. For instance: clj-ns-name automatically renames your buffers so they have the same name as the namespace name. That passively provides value, you don't have to know that that package exist or even that something is actively doing that, You automatically get value out of that. Syntax highlighting is another good example of passive value, and I imagine having a good clj-kondo setup out of the box can also provide passive value. You get warnings in your code without having to ask for them or having to know what is doing that. That means even complete beginners immediately get something out of it. passive return on complexity vs active return on complexity

clj-refactor provides some passive value, it automatically adds an ns declaration, but mostly it's active, you need to learn what it is, what it can do, and what the key bindings are to trigger it. I think clojure-lsp is similar (I may be wrong), there's a bit of passive value, but it's mostly active, you need to learn more things to make good use of it. Just setting it up involves a lot of informed choices. For packages like that the return on complexity is high for power users who take the time to study the docs and practice the key bindings, but it's low for a less advanced user who's still figuring out the basics of vim-style editing and interactive development. In fact it might be negative for new users who get overwhelmed with things they don't understand. "Smart" functionality can very easily get into people's way.

One of my annoyances with Spacemacs is that it loads a lod of things that only provide active value. Even after using it for years I would learn about packages that had been active all this time, that I didn't know exist, and that I had never used. I want to avoid that in Corgi. No "latent" functionality, we load the stuff that we know 90% of Clojure devs will get value out of.

So given all of the above I think the current situation is not wrong, we're being conservative so as not to load things that people might not get value out of, or that get into people's way. That said a lot of users are starting to swear by clj-kondo it seems, and I'm seeing a lot of appreciation for clojure-lsp as well, so I do want us to provide some kind of solution for those. My current thinking is a separate meta-package, maybe called corgi-clojure-smarts, that loads these two and sets them up.

But then we have to do it in a good way, make sure they have good defaults and integrate seamlessly, that any bindings are consistent with Corgi's approach to key bindings, and making sure that these things are properly explained in the Corgi manual. Our docs still leave a lot to be desired, but the goal is to have everything that is included with Corgi and that you need to actively know about to get value out of, to be explained in our own docs. You should be able to read the Corgi manual top to bottom and be productive, without having to branch out to other package's docs. (I guess I should write a separate issue for my vision on docs).

I've added this to my user config file to get word-wrap working more beautifully

(use-package adaptive-wrap
  :config
  (when (fboundp 'adaptive-wrap-prefix-mode)
    (defun my-activate-adaptive-wrap-prefix-mode ()
      "Toggle `visual-line-mode' and `adaptive-wrap-prefix-mode' simultaneously."
      (adaptive-wrap-prefix-mode (if visual-line-mode 1 -1)))
    (add-hook 'visual-line-mode-hook 'my-activate-adaptive-wrap-prefix-mode))
  (global-visual-line-mode t))

Without adaptive word wrap:

With adaptive word wrap:

Do you think this should be enabled by default? Or maybe again we can create this as a package

Currently Corgi uses Ivy, Counsel, Smex (although I just realize we are not actually binding any keys to use Smex), and Swiper. There have been a few questions about replacing these (#5, #14). Alternatives that have been proposed

by raxod502:

• Selectrum
• prescient

by oantolin:

• Icomplete Vertical
• orderless
• embark

by minad:

• vertico
• consul
• corfu

What we currently have: Ivy/Counsel/Swiper by abo-abo (monorepo).

I'm still from the time when it was Ido or Ivy so I find the current explosion of offers in this space a little overwhelming. We briefly switched to Selectrum and Prescient last year, but I quickly reverted the change. I remember being not satisfied with them at the time, but I don't remember what the issue was, see commit 776c4009048a9160cb0ec2f77cac4cacfdbf5888.

As a first step I think we need to make it easier for people to choose their own preferred packages here, that means splitting out the Ivy/Counsel/Smex/Swiper setup into a separate meta-package (corgi-completion? corgi-search?) so that people can load their own alternative.

We should also bind the commands these packages provide via signals. Some of them already are, e.g.

            :file/open counsel-find-file
            :file/open-recent counsel-recentf
            :jump/identifier counsel-imenu
            :buffer/incremental-search swiper

That way people can easily override this in their user-signals.el (see M-x corgi/open-user-signals-file).

Beyond that I would love it if someone could help do some meta-analysis, or point me at any good write-ups. Of all the packages listed above, which is an alternative to which? Which ones are bound to a specific underlying lib? What does each provide? etc. I've looked over some of these READMEs and feel none the wiser.

The straight.el package has moved to a new location https://github.com/radian-software/straight.el Guess we need to update the bootstrap.el file to reflect the new URL?

I keep finding myself doing lots of custom keybinds to either remove binds from specific maps or add them.

This means that my keybinds are no longer collected at one place and they are spread all over my init.el + custom corkey file.

Example:

((evil-define-key '(normal visual) evil-cleverparens-mode-map
    "s" nil
    "S" nil
    "{" nil
    "}" nil
    "[" nil
    "]" nil))

(with-eval-after-load 'evil-maps
  (define-key evil-motion-state-map (kbd ":") 'evil-repeat-find-char)
  (define-key evil-motion-state-map (kbd ";") 'evil-ex))

(with-eval-after-load 'dired
  (put 'dired-find-alternate-file 'disabled nil) ; disables warning
  (evil-define-key '(normal) dired-mode-map
    (kbd "RET") 'dired-find-alternate-file ; was dired-advertised-find-file
    (kbd "^") (lambda () (interactive) (find-alternate-file "..")))) ; was dired-up-directory

I think all of these could have been done directly from corkey, but then would that support deferred loading like evil-define-key or with-eval-after-load does? 🤔

First off, thanks for corgi. I really like corkey and appreciate the 'light weight' aspect of it (I'm a spacemacs escapee).

Looking at some of the open issues, it strikes me that some of them are stale and no longer valid. Is this the case and if so, should they be cleaned up?

FInally, main point for my post - I've made some tweaks to corgi and wanted to know if there is any interest in providing either a link to my repository or PRs. The changes I've made are

• Change from linum-mode to display-line-numbers-mode. A truly trivial change. Reason is dipslay-line-numbers-mode provides 'native' line numbers and is able to handle larger files better. Like linum-mode, it has been standard in emacs since Emacs 26. This change is so trivial, a PR is over-kill!
• Replace ivy, swiper, consoul and company with vertico, embark, consult and corfu. The reason I've made this change is that these packages are either part of Emacs or are built from existing emacs functionality. As a consequence, they tend to be smaller, less fragile and faster. However, they are not transparent replacements and therefore do incur some change adjustment overhead. I think all of them are either in ELPA or nongnu ELPA, so are available by default in Emacs 28.1 (which includes nongnu elpa out of the box).

This last lot of changes are significant and I can completely understand if the preference is to stick with the existing setup. Really just wanted to let you know that I do have a basic proof of concept using these alternatives which I can make available should you want to try it etc. Just my attempt to give something back because I really do like corkey - for me, that is the real gold in corgi!

I've been looking at a lingering issue in Corkey. When you pop up which-key with a prefix key it generally shows the descriptions provided in the binding/signal files as it should, but for some commands it just shows the function name.

The problem turns out is that which-key can't do minor-mode based replacement, and we have quite a few minor-mode specific bindings.

Going through the which-key sources it struck me that this package is doing a lot of stuff that we don't use/need/want, and the way it goes about its work is needlessly complicated. In Corkey we have all the information we need up-front, so we don't need to deal with replacement data structures. We can just render the normalized signal/binding data directly. Store that in a buffer-local var and be done with it.

which-key is also 2700 lines of code, I think it would be well within the spirit of Corgi to find something smaller that we can more easily adapt to our needs. Or potentially to take inspiration of what's out there and roll our own.

Main candidates I've seen

• guide-key (640 LoC) https://github.com/kai2nenobu/guide-key/blob/master/guide-key.el
• Hercules (215 LoC) https://gitlab.com/jjzmajic/hercules.el/-/blob/master/hercules.el

FYI I was unable to use this until I added the straight.el bootstrapping to init.el. But now it's nice; thank you :)

Is there in easy way to integrate 'jk' or 'jj' into the corgi configuration instead of 'ESC'?

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.

Fresh install of corgi under Emacs 28.1

Only just noticed there was a corgi-straightline package. This was mainly because it doesn't seem to be working. Had a quick look at the sources. Seems that it is operating on a face called mode-line-active, but there is no such face. There is mode-line and mode-line-inactive, but no mode-line-active.

Currently configuring my own fork of corgi so that I can provide some pull requests and will see if I can fix this.