Status and direction? about corgi HOT 6 CLOSED

I've cleaned up the old issues, and created a few new ones for discussion. Thanks!

from corgi.

Hi @theophilusx, thank you for trying out Corgi and providing input!

Development of Corgi has been done in a few spurts, mostly me working on it over two consecutive Christmas breaks. Since then we've done incremental improvements over time, but not a lot has happened because it's mainly been "good enough" for us for now.

Several people of the Gaiwan team have been using it for over a year with little issue. We're aware it's not perfect yet though and want to continue to improve it, and also to better promote it.

So far we've had almost zero user input. It's not clear if that's because nobody is using it, or if people are using it without major issues. Anecdotally I think we're slowly moving from the former to the latter, and I expect we'll gradually start seeing some more participation. So, welcome, and thank you for chiming in!

Recently I've been trying to put a little bit of time into Corgi every week to start polishing it up and documenting it better, we definitely want to continue to improve it.

To your points: yes, please swap out linum-mode, I didn't realize we were still using it. As you say display-line-mode is the way to go now. I think I wasn't aware of that yet at the time.

Regarding ivy/swiper/consul/company, this does seem to be an area where tastes vary. I believe @oxalorg is also using something else. I've looked at lighter weight alternatives but didn't like them. However I haven't heard of the packages you mention, so I'll check them out.

Maybe we will at some point change these out, but as a first steps I would start with isolating this category of functionality into a dedicated meta-package. It's currently bundled with some other stuff in corgi-editor I believe. By splitting it out it's easier for people to not load that package and instead set up their own preferences, or provide their own corgi-style meta-packages with alternatives to others.

We can consider afterwards if we want to pull those packages into Corgi proper, while still providing a meta-package with ivy and friends for those that don't want to switch.

Generally I want to stay away from providing "options" or "settings" for corgi. People choose which packages they want, and anything else they want they can do in their own config. This may be a rare case where having multiple alternative meta-packages makes sense, or maybe we'll just swap them out. Like I said I'd want to thoroughly evaluate these first.

from corgi.

Regarding the open issues, you're welcome to help clean those up!

from corgi.

I think moving the completion stuff off into its own module would definitely be a good move. Totally understand the hesitancy over changing or even providing options as it does tend to be something with considerable personal preferences. Moving it off into a module separate from corgi-editing would make it easy for people to comment it out and install their own. Would probably need to break out the very few key bindings which depend on them - maybe set them to default built-in functions and then, if the completions module is loaded, replace them with consoul versions etc.

I will send a PR to change the line numbering to display-line-numbers-mode. Happy to look at other issues, but could you do a quick review first? Some seem very old and no longer relevant, but I'm not 100% sure.

I notice the clojure configuration doesn't have any support for clj-kondo or joker. Is this deliberate (to keep things simple) or just low enough priority that nobody has gotten to it?

from corgi.

Would probably need to break out the very few key bindings which depend on them - maybe set them to default built-in functions and then, if the completions module is loaded, replace them with consoul versions etc.

Corkey should be able to handle this, if we make sure they are defined through signals. Then people can have a user-signals which will take precedence, we'll just provide some snippets. It's also possible to have an extra signal file provided through a (perhaps third party) package.

clj-kondo / joker

I personally don't use either. Some experiences earlier in my career have put me off from using linters entirely. I'm also not a fan of "nagging" tools that randomly start annotating and highlighting stuff, I find it very distracting and getting in the way of reaching a flow state.

I did try out clojure-lsp briefly (mainly to get jump to keyword in re-frame) but found it woefully immature, with frequent hanging and excessive cpu use.

So for the time being I'm going to opt keeping these things out. The good thing about being packages all the way down is that it's easy for people to provide their own additional or alternative corgi-style packages.

As they say in the Clojure world, no is temporary yes is forever. For something like this I would say: open an issue so people can share what they would like support for these tools to look like. That can also be a place where people can exchange snippets or promote their own packages, and then we have all the information in one place if we want to reconsider including it in corgi proper in the future.

from corgi.

Thanks. That helps a lot. I will have a look at how easily we can break out the completions stuff into its own module. I will also create my own external modules which are compatible with corgi for linting with clj-kondo and maybe eglot for clojure-lsp (I'm unsure about value of lsp in conjunction with cider). I'll make these additions available via my github and then open discussion issues here.

from corgi.