This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-20
Channels
- # announcements (3)
- # babashka (7)
- # beginners (36)
- # calva (71)
- # cider (25)
- # clj-commons (5)
- # cljdoc (19)
- # cljs-dev (5)
- # clojure (223)
- # clojure-austin (2)
- # clojure-bay-area (1)
- # clojure-europe (31)
- # clojure-france (6)
- # clojure-nl (2)
- # clojure-norway (19)
- # clojure-spec (13)
- # clojure-uk (7)
- # clojurescript (127)
- # core-logic (2)
- # cursive (21)
- # datalevin (53)
- # datomic (9)
- # emacs (37)
- # events (1)
- # graphql (8)
- # jobs (12)
- # lsp (8)
- # off-topic (92)
- # pathom (49)
- # pedestal (1)
- # polylith (3)
- # re-frame (25)
- # releases (2)
- # sci (11)
- # shadow-cljs (13)
- # vim (10)
@ericdallo I'm trying to make my first pull request to clojure-lsp. What is your development setup? Do you use make debug-cli
after ever time you made a change to the code? Is there an equivalent of hot-reload where you don't lose state when making updates to the build?
yes! this should help a lot: https://clojure-lsp.io/development/
The tutorial is awesome! One complaint: lsp-clojure-server-info does not open an actual split window and it crops many lines:
I haven't found a way to redirect the output to an actual window. This info disappears after any keystroke
you can access via *messages*
buffer, but yeah, we could improve lsp-mode to move that to a window
Oh I got it now. Didn't realize this is a message. Thought it's a temporary window with a weird behavior...
If I may also pitch Corgi here as an alternative to spacemacs, it has much of the feel of spacemacs but at a fraction of the size and complexity. It's the result of years of frustration running into issues with spacemacs and having a hard time debugging them because there is just so much going on. https://github.com/lambdaisland/corgi
@U07FP7QJ0 if I remember it, you briefly used Doom after Spacemacs, is that right?
I went for Emacs Live long time ago and now I am kind of rolling my own ...Emacs Live + borg framework - one day I'll have to simplify stuff and from what I am reading I like corgi
's idea
thanks for sharing
@U0G75ARHC no, never used Doom myself, I just answer Doom support requests for Chemacs2 😛
Thanks @U07FP7QJ0 Corgi looks like an excellent approach. I'm still very happy with Spacemacs, but I am interested in trying Corgi as an alternative. I found Doom too different in terms of user interaction, making it hard to switch
> no, never used Doom myself
Oh, I see. For some reason, I thought you left Spacemacs, then tried Doom for some time, and then decided to build Corgi.
I'm pretty sure if you explained the reasons why you moved from Spacemacs - I'd find (at least) a few relatable points. But I was curious to hear your thoughts on Doom and how Corgi's philosophy and structure differ.
So far, skimming through the documentation of Corgi, which I have to say - is very enjoyable to read; I specifically like the notion such as 'the framework shouldn't constantly be tossing a monkey wrench...',
https://github.com/corgi-emacs/corgi/blob/main/corgi_manual.org#packages-all-the-way-down
> it’s a standard Emacs config, and it’s your config
That was my main problem with Spacemacs - things often get intertwined, and even though I used Spacemacs-base and built my config mostly using my own custom layers, things would break unexpectedly due to upstream changes or additions that I never wanted.
It took me a couple of days to move to Doom. I simply started a list of features and keybindings that are important to me, and one by one either cherry-picked them from Spacemacs or found similar features in Doom modules or third-party packages.
Lots of things I like about Doom; I love its built-in macros: map!
, add-hook!
, after!
, et al.
https://github.com/hlissner/doom-emacs/blob/master/core/core-lib.el#L1
I don't know if you're familiar with them, and not sure if Corgi has anything similar. Check them out.
Also, I think it would be great if all Evil-based framework authors came together and worked out a single standardized convention for top-level and mode-based keybindings. It's such a mess right now - everyone does it differently - Spacemacs, Doom, Evil-collection. And that's just in Emacs-land, I'm sure, there are Neovim starter kits with "Spacemacs like" bindings, and they have it differently. We need an Evil taxonomist, some kind of Carl Vimmaeus to clean up this mess.
Corgi's probably not for me then, I'm one of those Emacs devs that don't like modal editing 😛
I still use Emacs though, but in Holy mode, that's what I like about spacemacs mostly. Though I should give Doom a try, it seems not using it for VIM like editing might be a bit ackward
That might also be why Spacemacs doesn't cause me any problems. I remember when using it in Evil mode, that whole vimification thing was hit and miss I felt.
I'll always advocate for rolling your own config (especially that use-package
simplifies a lot of the pain) and ditching your vi habits 😉
Agree on the first part, which is really what we're trying to encourage again > Corgi is an unbundled Emacs config. Instead of providing a full config we provide a set of packages (see corgi-packages) for use with Straight.el package manager. The Emacs config itself (the contents of ~/.emacs.d) are yours. We provide a sample-config. Hard disagree on the latter, see https://github.com/lambdaisland/corgi/blob/main/corgi_manual.org#vim-style-modal-editing
At this point I've been using both Emacs and Vim roughly the same amount of time and maybe because of that I'm not so religious about which way of editing is faster. Also probably because I spend more time reading and analyzing the code rather than writing it :man-shrugging:
Did you read the link? It's not about what is faster, it's about the risk of RSI. More concise is a nice bonus. I used Emacs for 12 years before switching to vim style, it was not the easiest transition, but I value my health too much to continue to flirt with RSI.
I can relate: I broke my wrist when I was 11 and suffer from it too - what made more difference for me was fixing my posture of all things, not so much the editor I use. There's so many factors to this I guess
I don't have RSI, but I've felt strains and transient pains from time to time after hyperfocus computering. For me three things help a lot, to keep things "normal". 1. Avoid typing in the first place (seriously, avoiding the "Repetitive" bit is useful). Lots of typing stuff for me is thinking / revision stuff. So I do that in my head or on paper / whiteboard. 2. Put Ctrl and Meta under my thumbs https://en.wikipedia.org/wiki/Space-cadet_keyboard, so no Emacs Pinky. 3. Use chording for moving around / yank / kill etc. I also use Vim, but separately. But I get how EVIL will give similar results. All of this presumes adequate keyboard, mouse, display, work-desk ergonomics. But all said and done, "methods to not need to type" category of stuff is the main thing for me. Additionally, "using one's body and strenghtening it" category of stuff is also fundamental to my, ah, process. IMHO strain injuries are rooted in mechanical imbalance as much as they are rooted in overuse.
WRT ergonomics and vim: I actually started using emacs instead of vi because I type in dvorak. The real win for emacs here is that you can change its ergonomics to your liking, which is what the most important aspect of ergonomics anyway -- personalization
I never really understood the value of Vim style editing until I learned how to speak the language of vim, ironically due to using Emacs/Spacemacs. After 20 years of IDE's and editors, switching to Vim-style editing made a massive productivity boost for me. It did take a couple of weeks to get comfortable, but I could feel the benefits as I switched The Vim-style key bindings feel so much simpler, therefore easier to retain, easier to touch type, than the chorded approach that Emacs uses by default. I used to use a very limited set of Cider commands when using the Emacs key bindings, as I found them very hard to remember If someone does not touch type, I assume the vim or Emacs approach makes a lot less difference. But for myself as someone who has touch typed since school, I greatly benefit from Vim-style editing and note a big difference when it's not available.
I find this really interesting - I always though of vi style modal editing as definitely superior to how editing works in emacs (and I'm a touch typist too, I learned on what looked like soviet era typewriters back in the 90's), but now I'm as proficient in the "emacs way" as I was when using vim. Maybe as not precise (I do miss things like d4w
sometimes). I suspect it's just down to me hyper-optimizing my own setup both in terms of hardware (mechanical keyboard with stiff keys to exercise my muscles) and software (I hand rolled my own config and have use a lot of sequential shortcuts like C-x p g
etc). I wish this was studied in more rigorous way
That would be super interesting, but might be near impossible to control for all the variables.
Yeah, indeed. I've seen some articles some years ago but they were mostly focused on "raw" WPM which in programming is not always as relevant
chording has always felt pretty good to me, but I used a keyboard with light actuation force (e.g. cherry mx reds) and karate chop the CTRL. nowadays I use a keyboardio model 01 and having modifiers on thumb keys is amazing
vim style editing is definitely better for navigating a single file, but do you find it better for navigating projects too?
Yes, I use vim-style key sequences for 99% of everything I do in Spacemacs. I navigate a project using projectile and navigate between projects using layouts (perspective), Both have a sequence of keys rather than chorded key bindings in Spacemacs. There are the odd chorded key bindings, like C-c C-e
to edit the results of a project search with helm-ag, but its a tiny amount
> no, never used Doom myself
Oh, I see. For some reason, I thought you left Spacemacs, then tried Doom for some time, and then decided to build Corgi.
I'm pretty sure if you explained the reasons why you moved from Spacemacs - I'd find (at least) a few relatable points. But I was curious to hear your thoughts on Doom and how Corgi's philosophy and structure differ.
So far, skimming through the documentation of Corgi, which I have to say - is very enjoyable to read; I specifically like the notion such as 'the framework shouldn't constantly be tossing a monkey wrench...',
https://github.com/corgi-emacs/corgi/blob/main/corgi_manual.org#packages-all-the-way-down
> it’s a standard Emacs config, and it’s your config
That was my main problem with Spacemacs - things often get intertwined, and even though I used Spacemacs-base and built my config mostly using my own custom layers, things would break unexpectedly due to upstream changes or additions that I never wanted.
It took me a couple of days to move to Doom. I simply started a list of features and keybindings that are important to me, and one by one either cherry-picked them from Spacemacs or found similar features in Doom modules or third-party packages.
Lots of things I like about Doom; I love its built-in macros: map!
, add-hook!
, after!
, et al.
https://github.com/hlissner/doom-emacs/blob/master/core/core-lib.el#L1
I don't know if you're familiar with them, and not sure if Corgi has anything similar. Check them out.
Also, I think it would be great if all Evil-based framework authors came together and worked out a single standardized convention for top-level and mode-based keybindings. It's such a mess right now - everyone does it differently - Spacemacs, Doom, Evil-collection. And that's just in Emacs-land, I'm sure, there are Neovim starter kits with "Spacemacs like" bindings, and they have it differently. We need an Evil taxonomist, some kind of Carl Vimmaeus to clean up this mess.