spacemacs 2020-02-26 | Slack Archive

Ah, I guess I am not the only that was surprised after updating to latest dev.

Sorry, we only spent 6 months off and on discussing the changes to the Clojure layer in this channel and via GitHub issues and two pull requests labelled as Clojure specific. I also added a detailed summary to the CHANGELOG.develop and extensively updating the docs to describe how to use the Clojure layer. Is there anything else I could have done that would help you 😁

spfeiffer15:02:19

@jr0cket I do not think this was an attack on you. Not everyone follows along here or studies GitHub issues or PRs before doing a git pull

practicalli-johnny15:02:55

I posted an explanation and a genuine question, I didn't take it as an attack, maybe I should have used more smile's 😁😁😁😁😁😁

😄 4

practicalli-johnny17:02:18

I do find it a bit strange that people don't take a minute to check what changes they are going to get before updating. I guess people like the thrill of the unknown :rolling_on_the_floor_laughing::rolling_on_the_floor_laughing::rolling_on_the_floor_laughing::rolling_on_the_floor_laughing::rolling_on_the_floor_laughing::rolling_on_the_floor_laughing:

spfeiffer18:02:52

Because there is no way to know for sure? I update irregularly. Currently i do not know how old my develop branch is locally. I need to check using git log , then compare to the commits made on github, where half of them touch layers i do not use, and half of the other half do not help me because i do not understand the commit message. I am an emacs user, not an elisp developer. Looking at PRs might be easier. But still much effort, for many people, i think.

spfeiffer18:02:49

I know what you want to say, but i think for many people, this is too much hassle for little benefit. Normally, things still just work after updating…

practicalli-johnny19:02:42

I also don't update Spacemacs (or packages) unless there is some benefit. Although I also update the develop branch when I am working on a pull request, so ensure it can be merged.

practicalli-johnny17:02:16

If I were a Machiavellian type of character, I could have great fun putting in things that are unexpected. And it is nearly April, so maybe I should think of an excellent Aprils fools to play...

Mario C.17:02:29

I did exactly that actually. git pull no questions asked. 😁 BTW I wasn't complaining, I was just surprised that the key-bindings, which are muscle memory at this point, were changed.

practicalli-johnny19:02:48

I thought I was going to have to change quite a few more keybindings, but after lots of discussion and getting a better appreciation of the overall Spacemacs conventions around keybindings, I managed to keep it to a minimum. Let me know if there any keybindings that seem incorrect, or illogical or especially anything that is missing. Thank you

practicalli-johnny20:02:07

My approach to checking what has been updated in Spacemacs is: 1. Open ~/.emacs.d/README.org or any other file in that directory 2. SPC g s to open Magit Status and l l to see the log, noting the title of the most recent commit 3. Review the closed PR's list until I reach the commit in Magit Log, https://github.com/syl20bnr/spacemacs/issues?q=is%3Apr+is%3Aclosed 4. If there aren't any interesting PR's then I dont usually update (unless working on my own PR) 5. If I do need something, then back to Magit status (`q`) in the log and F p to pull the latest changes 6. SPC f e D to check the .spacemacs-template hasnt changed (its fairly static now, but big change between master and develop ) 7. Finally update the Emacs packages from the link in the Spacemacs Home buffer, SPC b h and restart SPC q r .

practicalli-johnny20:02:25

I avoid an update if I have any kind of deadline or do not have time to fix anything (even though that rarely happens).

Mario C.22:02:07

Honestly the only changes to keybindings ive noticed are the , s c which used to clear the REPL buffer and SPC m s s which opens up the repl buffer. Now they are , s l and SPC m s a

2020-02-26

Channels