Creating a Corgi github org

[plexus]

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 Smart completion packages #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.

[plexus]

Unfortunately the corgi username is taken, so we can't name the org that. Maybe corgi-emacs? Any other suggestions?

[otfrom]

corgi-emacs for the org name sounds good

[jcmkk3]

This sounds like a good idea. I especially like the idea of splitting out corkey into its own package. I view that as one of the killer features of this emacs configuration. I also like the idea of removing the which-key dependency, as well. Maybe transient (now included in emacs 28) could be the basis for the keybinding display.

[plexus]

That's really good to hear :) I'm really happy with how corkey turned out! Is there anything in particular you like about it?

There's an issue with some notes (#13) about replacing which-key.

[plexus]

Corkey is now its own repo, and I wrote up what I think is a fairly complete README. I was surprised I hadn't done a better write-up before, besides a few paragraphs in the corgi manual. This will hopefully help clear up some confusion and help people appreciate how they can leverage the power of Corkey.

Since the key bindings themselves are policy not mechanism I've split them into a separate corgi-bindings package, which will likely remain under corgi-packages.

I've also moved corgi, corgi-packages, and walkclj to corgi-emacs, extracted clj-ns-name from plexmacs, added READMEs to walkclj and clj-ns-name, and added a .github/profile/README.md which shows on the corgi-emacs org page.

There's a bunch of churn going on right now, so expect fresh installs to be broken for the next couple of days. I can only spend a bit of time on this every day, but I think we should be in a more stable state again by the weekend.

Basically my plan is

• extract the packages I want to extract (all the "mechanism" packages)
• move them all to corgi-emacs
• update the straight package repo (corgi-pacakges.el) so all the git references are correct
• update the sample config to reflect some of these changes
• write up some CHANGELOG notes to help existing users migrate (will have to change a few lines in their config, not much)

[plexus]

I've migrated everything to corgi-emacs, and made sure the sample config works again. There are still a few packages I'd like to extract, but I'll do that in a second pass, I wanted to get to a stable point again first.

Left to extract

• corgi-stateline
• pprint-to-buffer

I would really appreciate it if folks could try out migrating their own config.

• in bootstrap.el (if you follow the sample layout), change the packages repo location from lambdaisland to corgi-emacs

(use-package corgi-packages
  :straight (corgi-packages
             :type git
             :host github
             :repo "corgi-emacs/corgi-packages"))

When loading corgi-stateline, also enable it, since it's a mode now

(use-package corgi-stateline
  :config
  (global-corgi-stateline-mode))

Include corgi-bindings, the corgi-keys/corgi-signals files are in here now

(use-package corgi-bindings)

Remove the corgi-packages versions from straight/versions/default.el, to force it to upgrade.

# On Linux you can do this, -i doesn't work the same way on mac, in that case just do it manually
sed /corgi-packages/d -i straight/versions/default.el

What I would recommend after that is to remove straight/repos and to move straight/versions/corgi-versions/corgi.el out of the way. You may want to keep it somewhere for reference, in case you want to revert any package later on. I did some general version bumps so we might discover breakage.

Now start emacs and let it rebuild. I would recommend not shutting down your existing instance just yet, leave it running so you have a working editor to potentially troubleshoot and fix issues.

I would run this one separately in a terminal

emacs -nw --debug-init

That's going to be busy for a while downloading and rebuilding. You'll get a lot of warnings too, I've tried to clean up most of our warnings, and actually found a few bugs that way, but it's still showing many, most in other packages.

[theophilusx]

Just FYI I tried a quick fresh vanilla install, but it fails with a wrong type argument; sequencp normal error, which I'm guessing is related to bindings or corkey. Unfortunately, adding --debug-init does not generate a backtrace, so I've not yet narrowed it down.

This is with the sample config from a fresh clone of corgi-emacs/corgi

[theophilusx]

UPDATE: Looks like the issue is with corgi-stateline. Having a look now.

[plexus]

I just pushed a fix, can you try again?

[plexus]

The problem was with cl-case, interpreting this (normal ...) as a function call

(cl-case evil-state
  (normal ...)
  (visual ...)
  ...)

I've seen that happen before, that you're doing something in a macro, but sometimes it doesn't realize it's a macro. It happened in the past with parseclj/parseedn where people would report these bugs on specific versions of emacs, and I would rewrite that in simpler terms (as I did here, just used a cond).

I think it might have to do with the fact that I wasn't requiring cl-lib explicitly, and so the compiler didn't realize it's actually a macro?

[theophilusx]

Yes, just found it as well. You might be right re: require cl-lib. It does seem to work if you put it in a list i.e.

(cl-case evil-state
  ((normal) ...)
  ((visual) ...)
  ...)

but shouldn't be needed if it is working correctly as a macro.

Will pull the update and test now.

[theophilusx]

Yep, that seems to have fixed it. Successfully installed a fresh vanilla version - now off to update my version.

BTW I've found a few problems with the current completions setup (found before the changes). Will put together a PR with fixes for review. You may notice one of the minor 'errors'.

As an example, you may have noticed one. When you do M-x global-corgi-stateline-mode, it echos a message telling you that you can run the command with a shorter name. Unfortunately, that facility doesn't work with ivy and in a normal ivy install where you set M-x to consel-M-x, ivy disables the short command name feature to prevent user confusion.

[plexus]

Strangely I don't think I've ever seen that message... Maybe I didn't notice or maybe it's a setup difference?

[theophilusx]

It flashes past quickly and is followed by the message about the mode being enabled. However, you should be able to see it in the Messages buffer. I certainly see it with a vanilla install.